Widelands searches system paths for its data files by default.

[SirVer]

Related to bug 615891.

Widelands is configured at compile time where it looks for its files. By default on Linux it looks in /usr/share something…

Before it checked in each datadir it could find if the VERSION file was the same as the binary and would prefer that. I removed the check in http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/7015.1.43 for two reasons: one I think the filesystem code is not the right place to check for something so specific and second because I thank that Widelands should not search for its files until explicitly configured to do so. I did not touch the specific code because I am not sure if some maintainer are relying on the defaults.

I think the correct approach is to hardcode CMAKE_SRC_DIR as the datadir (the read only directory for data) until explicitly overwritten by CMAKE options on build. This will keep all flexibility for the various installation options people like through CMAKE parameters, but makes also more sense for development. Are there other opinions?

Could anybody who knows something about Linux look into how this should be done, so that our PPA do not break?

[Jens Beyer (qcumber-some)]

I can possibly look into that.

One thing though: WL_PORTABLE can not work with CMAKE_SOURCE_DIR but needs . for the data directory. Same on Windows.

On Linux without WL_PORTABLE, we should stick to the CMAKE defaults regarding CMAKE_INSTALL_PREFIX (/usr/local) and code the locations as such (if not defined when calling cmake).
On Debian/Ubuntu (which also means our PPA) we have to take care about the locations but as you said this should be doable.

[Hans Joachim Desserud (hjd)]

Regarding the Debian package, it sets several paths explicitly when calling cmake. See override_dh_auto_configure in http://bazaar.launchpad.net/~widelands-dev/widelands/debian/view/head:/debian/rules for details.

[SirVer (sirver)]

> WL_PORTABLE

I find this to be confusing. I think this should go away and the default should be:

WL_INSTALL_PREFIX = empty, we do not install.
WL_INSTALL_DATADIR = ${Source dir}
WL_INSTALL_LOCALEDIR= empty, we do not install
WL_INSTALL_LOCALEDIR = ${build_dir}/local

if anybody needs anything different (i.e. for deploying a .deb or what not), they should change these options. make install should either not work by default or be a noop.

What do you think?

[Jens Beyer (qcumber-some)]

Well I am doing make install/ninja install all the time ;-)

But you may be right, most people won't do it.
The only people who *need* to do it are those working on packages (or on source distributions).
If people *want* to do it (like me), it is calling for some (well documented) manual parameters.

Mind you, if you don't set CMAKE_INSTALL_PREFIX, make install will always work (default: /usr/local)

I guess I will try to make a branch which then should be tested furiously by all stakeholders, including our PPA builders and Mac/Win packagers.

[SirVer (sirver)]

> Mind you, if you don't set CMAKE_INSTALL_PREFIX, make install will always work (default: /usr/local)

I learned that today... that was unexpected behavior for me for sure :P.

> I guess I will try to make a branch which then should be tested furiously by all stakeholders, including our PPA builders and Mac/Win packagers.

sounds like a plan.

[Teppo Mäenpää (kxq)]

Has somebody already worked on this?

I have latest release installed to system dirs, plus the trunk in its own tree. Previously this worked fine, but now the trunk wants to read its supplementary data from the system dirs and fetches build 18 data, which leads to a diseaster.

[SirVer (sirver)]

Nobody has worked on this IMHO. Just for reference: the breaking commit is http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/7015.1.43. I still think that change I did there is reasonable though - the VERSION file is a Widelands extension and should not be handled in one (arbitrary) filesystem implementation. And I still think that the correct fix is the one discussed here.

[SirVer (sirver)]

Fixed in r7197.

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.