Configuration & Packaging

[Zini]

We have most of the core tasks for 0.12.0 either assigned or finished. mwrender is making good progress and animation will surely follow soon after. I assume that Journal GUI also makes good progress.

That means there is only one showstopper left that is not tackled yet: The new configuration system and packaging automation. One task has already been addressed by Yacoby.

This leaves us with the following issues:

* Automatically pick up the path of existing MW-installations
* Handle resources across multiple data directories
* Generate a suitable default-value for --data-local
* Need to create app bundle using CMake, not by hand
* Automate Packaging

This one is complete, but requires more testing (especially on Windows):

* Cleanup Configuration File Handling

And then we have this task, which is essentially a summary of all the other tasks. It contains a detailed description of how the configuration system should work.

Unfortunately nearly everything here is platform depended. That means we will need three people working closely together on this issue.

Since this will require a lot of back and forth between individual developers, I assume these tasks will take a while to finished even though they don't require that much work. It would be good if we could get started on them soon, so they will not delay the release.

I can offer some advice for most of the tasks (except for highly Windows- or OS X-specific parts), but I probably won't take part in the actual implementation.

So, do we get any volunteers?

[corristo]

I'm ready for OS X

[Zini]

Okay, that is a start. I suggest you have a look at Need to create app bundle using CMake, not by hand, because this is the only part that does not involve other platforms.

[swick]

I can help with ubuntu 11.10 64, 32 and windows 7 64.

[Zini]

Okay. Then we have all platforms covered. A good start would be to find out how to embed various system information in paths.

Most important here is the data path. A short reminder: The data path determines where OpenMW is looking for ESX files and MW-resources (meshes, textures, ...).
We can have several data paths and we also have the local-data path. A data path pointing to a directory that does not exist, should be ignored. These paths are ordered (a resource in a later data path should take priority over one in an early data path, with local-data having the highest priority). The location the data path is pointing to is usually not writable. The exception here is the local-data path, which usually points to a suitable location somewhere below the users home directory.

Now we need the following:

We need to be able to embed the value of a system variable or a registry setting in a path.

Example: Somewhere in openmw.cfg we could have something like this:

Code: Select all

local-data=$$HOME$$/.openmw/

which would translate on an every Linux box for UserX into:

/home/UserX/.openmw/

We need to be able to do the same with registry keys. Let's say:

Code: Select all

data=##someRegistryKey##/data/

Note that both $$ and ## are only examples. You should pick something that isn't allowed in a regular path on all three systems.

Also note, that on Linux (and on OS X too?), OpenMW should test if Wine is installed and if it is get the registry setting from WINE.

I am not entirely sure where best to implement this feature. Maybe somewhere in components/files or components/cfg.

[safferli]

Shouldn't the freedesktop standards be adhered to? http://standards.freedesktop.org/basedi ... atest.html

So, /home/username/.config/openmw ?

[Zini]

That line was also only an example. We will figure out the exact locations once we can automatically point to them.

btw. for configuration file we are already using the location you mentioned. I guess it would not be unreasonable to use it for data-local, but we will have to look into this more closely.

[sirherrbatka]

And what about steam? How does it work?

[Zini]

AFAIK the steam version of MW does set the required registry entries in the same way as the original MW release does. But it would be nice, if someone could check.

[swick]

wanted to start today but since I can not even compile components it looks like it will take much longer...