Fix system install of package and use ../share/oolite folder for Resources and AddOns

[mcarans]

Fix system installation of Oolite with meson - separate assembling folder after compilation (post build) from installation which now has a separate install script
Use ../share/oolite folder for Resources and AddOns for system install, Arch packages, appimage and flatpak (will also help with anyone wanting to make Debian or Fedora packages in future)

[LW-archlinux]

pkgname=oolite-git

meson setup $pkgname _build \
    --backend=ninja \
    -D debug=false \
    -D strip_bin=true \
    -D b_lto=true \
    --wrap-mode=nofallback \
    -D prefix=/usr \
    -D bindir=bin \
    -D datadir=share/$pkgname

Resources folder is installed to datadir/oolite instead of datadir .

both oolite (executable) and run_oolite.sh are installed to bindir, but run_oolite.sh tries to start /usr/share/oolite-git/oolite instead of /usr/bin/oolite .

Also oolite stable and oolite trunk will conflict if oolite and run_oolite.sh are both in bindir making it harder to switch between those 2 versions.
That is a minor issue as trunk conflicting with stable is very common .

[mcarans]

There are various problems to solve here. meson sets datadir by default to /usr/local/share, so I think what is needed is to be able to pass pkgname with default oolite as an option to meson so that you would supply datadir=share .

However this is quite complicated because the Obj-C assumes ../share/oolite and so that would need to receive and use this pkgname too ie. it would need to look for Resources in ../share/<pkgname>/Resources instead of the hard coded ../share/oolite/Resources.

The meson install would need to rename the executable it produces oolite to <pkgname> and run_oolite.sh to run_<pkgname>.sh with the executable name in run_<pkgname>.sh updated accordingly.

[LW-archlinux]

both oolite (executable) and run_oolite.sh are installed to bindir, but run_oolite.sh tries to start /usr/share/oolite-git/oolite instead of /usr/bin/oolite .

This was due to me setting OO_EXEDIR before calling run_oolite.sh . commenting that out makes run_oolite.sh start oolite from bindir (/usr/bin) correctly .

../share/oolite ../share//oolite

Using relative directories in paths tend to cause issues because .. to climb one level makes assumptions about what exists 1 level up. Those assumptions can be wrong.

Using absolute paths like $prefix/$datadir in the executable seems by far the best method to get rid of relative paths in sourcecode .
No clue how to use that for flatpak / appimage and/or Other OSes though.

[mcarans]

This was due to me setting OO_EXEDIR before calling run_oolite.sh . commenting that out makes run_oolite.sh start oolite from bindir (/usr/bin) correctly .

Does this mean that when you put datadir=share, the game works ok for you?

Using relative directories in paths tend to cause issues because .. to climb one level makes assumptions about what exists 1 level up. Those assumptions can be wrong.

Using absolute paths like $prefix/$datadir in the executable seems by far the best method to get rid of relative paths in sourcecode . No clue how to use that for flatpak / appimage and/or Other OSes though.

The meson way is indeed to pass all those things into the build, but it's a(nother) potentially complex change, so if this PR works ok, I'd like to merge it first. Then look at pkgname, prefix and datadir stuff separately. Does the game build, install and run for you with this PR?

[LW-archlinux]

Does this mean that when you put datadir=share, the game works ok for you?

Not entirely ok.
It runs, finds savegames and addons, but doesn't use ~/GNUSTEP/Defaults/OoliteDefaults.plist .
Instead it creates a new oolite.plist file in that folder.

EDIT
copying OoliteDefaults.plist to oolite.plist does make oolite use the settings.

[mcarans]

Does this mean that when you put datadir=share, the game works ok for you?

Not entirely ok. It runs, finds savegames and addons, but doesn't use ~/GNUSTEP/Defaults/OoliteDefaults.plist . Instead it creates a new oolite.plist file in that folder.

EDIT copying OoliteDefaults.plist to oolite.plist does make oolite use the settings.

I've asked about this behaviour here: gnustep/tools-make#73 (comment)