Oolite Bulletins

Hi,

Today I finally managed to compile Oolite 1.81 from git on my Gentoo system.

I have been hit by several problems which I had to circumvent (thanks to FreeBSD people and to the ebuild from Gentoo rion Overlay). The reported errors were not really helpful in solving the problems.

I have been working with buildsystems in the past (last major project was transition from SCons to CMake) and wonder if a different, more featureful build system (I am currently thinking about CMake) would be helpful for Oolite. It would basically create the Makefiles automatically from configuration, which could also test for dependencies and include/exclude libraries etc. based on the system it is compiling on.

What do you think?

Sounds good to me..

I just wanted to ask that, whatever gets done, is done Linux-side only, without affecting anything in the Windows make system. Windows and Linux use the same build system (Makefile/GNUmakefile) but they are independent of each other by means of #ifdefs etc. Right now, the Windows build system allows one to go from a fully clean code check-out to a ready-to-deploy installer with one command and I would like to keep this unchanged.

another_commander wrote:

...Right now, the Windows build system allows one to go from a fully clean code check-out to a ready-to-deploy installer with one command and I would like to keep this unchanged...

The same is valid for the Linux distribution-neutral installer.
Since you have already resolved the issues, perhaps, a sticky walkthrough post in the Oolite-Linux sub-forum would address the case for future reference.

Getafix wrote:

another_commander wrote:

...Right now, the Windows build system allows one to go from a fully clean code check-out to a ready-to-deploy installer with one command and I would like to keep this unchanged...

The same is valid for the Linux distribution-neutral installer.
Since you have already resolved the issues, perhaps, a sticky walkthrough post in the Oolite-Linux sub-forum would address the case for future reference.

The walkthrough post in the Linux sub forum is certainly a good idea, I will do that.

Would you mind sharing the single command line for the Linux distribution-neutral installer?
In theory, it should be doable for Linux and for Windows (don't know really about MacOS) with CMake+CPack+NSIS Installer in one make call. There are practical hindrances with the CPack+NSIS though, which might pose some problems, or not.
I guess I will try to do it with CMake anyway just for the kicks of it (low priority project though). If I can come up with something useful and nice in the next half year, I'll let you guys know and you can then see for yourself

To build the Linux distribution-neutral installer you have the following options
make -f Makefile pkg-posix <--- builds a release self-extracting package
make -f Makefile pkg-posix-test <--- builds a test release self-extracting package
make -f Makefile pkg-posix-snapshot <--- builds a snapshot release self-extracting package

Now for the nightly build installer the command is
make -f Makefile pkg-posix-nightly <--- builds a snapshot release self-extracting package for the nightly build
(the difference in the nightly build is that the package naming and the installation folder naming changes, in order to be able to coexist with a normal Oolite installation; the "-trunk" is used as label in this case)



At this point I need to explain a small 4-step trick that we perform in order for the installer to work in various distros
(e.g. Fedora, openSUSE, debian, [X,K,L]Ubuntu, Mint, Slax etc. - back in 2009 it even worked on a Linpus Lite based Acer One!!! )
(this is why we call it "distribution-neutral"... it's not for ALL the Linux distros but for many of them.)

Step 1
The main libraries, that Oolite depends on, have been manually installed from source (i.e. configure, make & make install) in the system that is used to produce the publicly released installer.

Step 2 improvement alert!-improvement alert!-improvement alert!
The source code script
deps/Linux-deps/[x86, x86_64]/lib_linker/make_so_links.sh
is used to generate symbolic links pointing to the libraries, to be packaged, using the short name of the library.
This symbolic link name is used at the time of compiler objects linking (see GNUmakefile).

Step 3
The installer is packaged to carry these exact same libraries.
The binaries packaged are located in the source code tree folder
deps/Linux-deps/[x86, x86_64]/lib
NOTE: These libraries will NOT be installed in the user's system. They will just be copied, during Oolite installation, in
Oolite[-trunk]/oolite-deps/lib/
installation folder, they will only be visible by Oolite and they will be deleted when Oolite is uninstalled.

Step 4
One final step is performed every time the user is actually executing Oolite. The command
export LD_LIBRARY_PATH=${OOLITE_ROOT}/oolite-deps/lib
is executed to indicate to Oolite to look into this path first for its libraries, before the standard set of directories.



I know that this is a "trick" and does not follow any Linux standard or best practices but...

1. it has proven to work for more than 10 years (does anyone still remember the Autopackage era?)
2. it doesn't mess with the user's system libraries
3. it gives a safe uninstall to the user (library dependencies of other applications are not impacted)
4. troubleshooting a user's issue is contained to Oolite code and not to any bleeding edge latest version library the user may have in the system.
5. it has made the Nightly Build for Linux feasible
   • avoid the operational activities nightmare to support various Linux distros, flavors, versions native installation policies
   • one package format fits all (avoids also the debate between competing installation package formats for Linux such as .rpm and .deb)
6. Oolite new releases can be scheduled independently of each distro processes, policies and release schedules for new versions of third party software:
   • Oolite Linux can be released together with Mac and Windows
   • any new Oolite Linux release is made available, for all Linux users that have Oolite running, simultaneously and independently to their respective Linux distro
7. common Oolite file hierarchy system for all Linux distros
   • makes feasible a common and simple functionality of upgrading from one Oolite version to the most current one, without the need of downloading the full version (call me oolite-update).
   • easier troubleshooting (specially when you give instructions to the user for locating installation files)
8. All of the above considering the handful of near (or already there) middle-aged people that are managing Oolite in parallel with RL.
9. For as much as it worth, Linux users with distros dated as back as 2009 (e.g. just tested v1.80 and trunk on a debian "lenny") can still play current versions of Oolite.

QCS wrote:

...If I can come up with something useful and nice in the next half year, I'll let you guys know and you can then see for yourself

I am also interested in this attempt, so as soon as you have something working, I will be more than willing to test it in order not to risk any of the aforementioned benefits of the current approach (or as less as possible).