Make orxonox distributable

[Nowic]

I tried to create the infrastructure to build Debian/Ubuntu packages of Orxonox. The data package is done, but the application is nearly undistributable from a Unix/Linux point of view.

Please add/change the following:
* do not write files everywhere. All user configuration (and logs) should be written to a fixed directory in the home directory (e.g. .orxonox)
* Please add 'make install', 'make distclean' and 'make dist' to the build system. This should be easy as 'make' and 'make clean' are already working fine.
* the helper script to run the game (./run) should not be needed when distributed

Whishlist:
* Try to avoid bundling third party libraries without changes (e.g. tkl)
* Make sure (and document) that all your data has free licences

thanks,
nowic

[beni]

Hey nowic

Fine thing there helping us with the distributing. A debian package (especially one that can be updated every now and then) is a big win for us to gain a bigger user base.

Whishlist:
* Try to avoid bundling third party libraries without changes (e.g. tkl)
* Make sure (and document) that all your data has free licences

I guess you are referring to tcl. We have some wrapper libraries bundled like tinyxml and tolua++ because there is no Debian package available for them. Meaning that the user would have to download the source himself and compile it, which is really not comfortable. Correct me if I'm wrong, but we bundle only the things, we think are a bitch to get elsewhere.

About the data I'm pretty sure that is the case. There may be something which we don't really use, but the data branch should be clean of strange non-free data. About the documentation: What would you suggest is the best way to do that?

Thanks again for helping us with that

[Nowic]

Yes, it's okay if the libraries are not available. Yes tcl... I don't realy know what kind of scripts you need, but it looks like the base-library? If these libs are needed for windows, you could exclude them on other OS in your build system.

tolua seems to be available: http://packages.ubuntu.com/hardy/libtolua-dev

But anyway, the issiues on top are more urgent.

For the data repository: It would be nice to have a COPYRIGHT file in the root of the data repository with a list of the licenses, all the authors and a hint what they did. Or maybe seprarate license files.

[x3n]

We're not including the tcl library... if you are refering to CppTcl: it's a wrapper to use tcl in c++ and not a library. It's a single source file and if you're talking about the tcl scripts in our media repository: They _are_ changed and it's only scriptcode, no "library" in the strict sense.

But anyway, this wasn't the important point in your post.

* do not write files everywhere. All user configuration (and logs) should be written to a fixed directory in the home directory (e.g. .orxonox)

Well, we're only writing some files into the orxonox/bin folder. There are some dynamically generated source files too, but they wouldn't make sense in other directories.
Why is it a problem to write logs and config files into the bin directory? Or are you talking about something different?

* Please add 'make install', 'make distclean' and 'make dist' to the build system. This should be easy as 'make' and 'make clean' are already working fine.

We'll have a look into cmake. It shouldn't be a big deal to add those modes.

* the helper script to run the game (./run) should not be needed when distributed

I cant help with that, but there are other people knowing more about linux


Anyway, thanks for your work

[Nowic]

We're not including the tcl library... if you are refering to CppTcl: it's a wrapper to use tcl in c++ and not a library. It's a single source file and if you're talking about the tcl scripts in our media repository: They _are_ changed and it's only scriptcode, no "library" in the strict sense.

Ok But libraries can also consist purely out of scripts.

* do not write files everywhere. All user configuration (and logs) should be written to a fixed directory in the home directory (e.g. .orxonox)

Well, we're only writing some files into the orxonox/bin folder. There are some dynamically generated source files too, but they wouldn't make sense in other directories.
Why is it a problem to write logs and config files into the bin directory? Or are you talking about something different?

In an Unix or Unix like operating system, you, as a user, do not have the rights to write into the 'bin' folder or any other application data directory. Users are only allowed to write into /home/username and /tmp. Software should not 'mutate' like in some proprietary operating systems.

[x3n]

oh. ok. I didn't knew that. In windows it's quite usual to locate the config-files in the same directory as the binary, because, you know, why wouldn't they? Everything is at the same place... The mentality of spliting software into several pieces and spreading them over the whole system was something I disliked the most when trying to friend up with linux.
But anyway, we'll implement a home directory for linux, no problem.

[beni]

I really like the development in this thread.

About the run-script: It was written by Nico to ensure that some files get configured the right way. I guess it can be replaced with a few tweaks. However we would have to let Orxonox find out where Ogre is and how it can access the plugins of Ogre.

As x3n already said, the config files should easily be able to be put into a user dir.

[Nowic]

The run script is fine for development purposes, so you don't have to remove it. But 'make install' should not install it, as it will (should) know where the libs are. The .deb will know that too. Can't cmake detect these directories?

[Nowic]

As nobody seems to work on these problems, I looked at cmake to improve the situation. After reading the manual, I'm not really convinced of cmake. Yes, it is easy to read, but it does not support 'make uninstall', 'make distclean' (remove all files that the build system created) and 'make dist' (create a clean tar.gz (or zip) for the enduser).

Here are the changes for a working 'make install'. Please apply these changes to the trunk. they should not distract anybody. Thx!

Code: Select all

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt	(Revision 1597)
+++ CMakeLists.txt	(Arbeitskopie)
@@ -100,6 +100,12 @@
   ${ZLIB_INCLUDE_DIR}
 )
 
+#Installation of the binary and default configs
+IF(UNIX)
+    INSTALL(PROGRAMS bin/orxonox DESTINATION games)
+    INSTALL(FILES bin/ogre.cfg DESTINATION share/games/orxonox)
+ENDIF(UNIX)
+
 #add main source dir
 ADD_SUBDIRECTORY(src)

All hacks I did to get a working debian package:
http://wenner.ch/files/public/simon/orx ... ll_1.patch

These changes should not be applied but they hint at some problems.
The resulting debian packages (orxonox and orxnox-data) are installable but the game crashes as it wants to load levels/sample.oxw, which is not part of the data repository.

So two main problems remain to make it distributable:

1. Clearly separate code from data (move the levels)
2. Clean up the configuration paths mess! -> create a orxonox configuration directory on the first startup and copy the default configs into it.
- Orxonox needs many configuration files and they are handled very inconsistently.
- Keep in mind that plugins.cfg can be supplied by the distribution.
- Every time I run the installed orxonox I end up with the following files in my directory: default.ini, def_keybindings.ini, keybindings.ini, orxonox.ini, orxonox.log and translation_default.lang. wtf?

[beni]

I may have some time the following week (depending on what my friend has planned for that week) so I'll add those changes into my branch and submit them to the trunk after successfully merging it.

Most problems should be easily fixable, as they do not require much changes in the code. However I do not know if I break stuff Windows-wise. But this'll be another story.

[Nowic]

nice to hear!

[1337]

I can only join Beni and work something out for windows. We need at least precompiled dependencies that get updated regularly (for both msvc and mingw).

[beni]

So where are we here? Obviously 'make uninstall', 'make distclean' or 'make dist' still won't work, but what about the other things? We still have the run-script, but we don't really need it and make install would not use that anymore. I'll try to freshly install Orxonox on another linux system to check how much end-user friendly it is.
If this works out, we could also start to make nightly builds on the server.

The data/media stuff is now in discussed in another thread.

[1337]

make uninstall is not supported by CMake unfortunately.
But make install should work properly (but only tested on about three Unix boxes and one windows box).

The catch is that you have to do quite a lot of steps to get orxonox, but we have guides for that.

[greenman]

i think when we put orxonox in a distributable format (like debs, rpms, ebuilds, self-extracting installer) there is only a few steps for the end-user to take until orxonox is playable or am i wrong?