I saw in the roadmap "Compiling and packaging Windows release ", OK I can try to handle that one. But what should be included in the packaging? There was a suggestion to include and link only required parts of Ogre3D, perhaps it could be nice to treat that item before finishing this point (in the next release, update the roadmap). It could be nice to remove some unneeded MBytes.
Compiling on VS Studio is OK, but what are the packages that should be included (Ogre3D dll and .cfg files), and what form should it take (zip, setup)?
What do we assume of the user config, do we have to search the dir of Morrowind install or let the user find it, where will the files be installed, is there a conf variable (ini or stuff like that) that will tell where the Morrowind data files stands?
I think that the package should be as simple as possible, so it coud be better to include whatever libs needed (Ogre3D and any other libs).
It could be fine if we can deliver a complete setup, which will ask the user where are the data files. It could also be fine to also deliver a standalone zip with just a .ini file to update with the data files dir name.
Do I miss the point?
What is your point of view about how we should handle the packaging?
Zini wrote:
Well, not a Windows user currently, but I propose to make it as simple as possible. A simple zip file with all files needed to run OpenMW should do the job.
An ini file for selecting the Morrowind data directory makes sense. That would require some coding first though. Currently the directory is hard-coded.
I think the required files besides the main executable are:
Not sure about BSPSceneManager plugin for Ogre. It is listed in plugins.cfg. But are we using it at all?
Edit: Apparently not. So the BSP entry could be removed from plugins.cfg and there is no need to include the plugin into the zip file.
Zini wrote:
I have implemented the data file handling in my fork. It works like this:
The user can specify the data directory in a command line option named --data.
If he doesn't do that, openmw looks for a key named data in a file named openmw.cfg.
If this file isn't there or if it doesn't have the key, OpenMW defaults to the directory "data" in the execution directory.
Zini wrote:
And it is in the main repository now.
Ideally the whole packaging procedure should be automated (a script, that collects all the files and makes a package from it).
There is a companion tool to CMake named CPack, which can automate the packaging process based on the existing CMake infrastructure. For OpenMW we would need to add install rules first though and I don't know if the Windows version has a generator for zip files. Actually I have no idea how well CPack on Windows works. Doing it by hand might be easier after all
Edit: If you are serious about the packaging job, you could as well insert your name into the roadmap table ("Assigned to" column).
nicolay wrote:
pogzy wrote:I saw in the roadmap "Compiling and packaging Windows release ", OK I can try to handle that one.
Great, thanks! I think Zini covered most of your questions, let me know if there's anything that needs clarifications. I'll answer this one:
I think that the package should be as simple as possible, so it could be better to include whatever libs needed (Ogre3D and any other libs).
In my experience from the previous releases, the separate DLL package zip worked quite well. It meant having one zip with the .exe and config files and so on, and another with all the library DLLs. Since the DLL zip was typically much larger than the main zip, people didn't have to redownload it if only the exe changed. But feel free to do it any other way - maybe one big zip with both is just as good.
pogzy wrote:
Hi,
Two separate zip are helpful to limit bandwidth consumption, but one package as simple as it could be should remain our main goal. Two separate zip could be provided as an optional download.
