Oolite Bulletins

Hello,

After several monthes, I've tried to build a new time the oolite package from source.
I've download this from the subversion repository and launch the make command ( # make -f Makefile deb-snapshot ) and the build stop with error messages meaning than some files were not found ... In fact the deps were changed and the debian/rules script isn't up to date.

I would like to correct this. Is somebody could indicate to me how oolite is built out of Debian package on linux system, autopackage for example ?

Regards,
B.

Here the diff I've made to debian directory files to compile oolite :

Index: debian/oolite-data.docs
===================================================================
--- debian/oolite-data.docs (révision 4318)
+++ debian/oolite-data.docs (copie de travail)
@@ -3,6 +3,5 @@
Doc/README_LINUX.TXT
Doc/ReadMe.rtfd/TXT.rtf
oolite.*/Resources/README.TXT
-deps/Linux-deps/PLAYING.TXT
Doc/OoliteRS.pdf
Doc/contributors.txt
Index: debian/rules
===================================================================
--- debian/rules (révision 4318)
+++ debian/rules (copie de travail)
@@ -9,7 +9,7 @@
# Tweaked by Michael Werle

GSMAKE = gs_make
-JS_SRC = deps/Cross-platform-deps/SpiderMonkey/js/src
+#JS_SRC = deps/Cross-platform-deps/SpiderMonkey/js/src

CFLAGS += -g
ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -28,8 +28,8 @@
build: build-stamp
build-stamp:
dh_testdir
- $(MAKE) -C $(JS_SRC)/fdlibm -f Makefile.ref BUILD_OPT=1
- $(MAKE) -C $(JS_SRC) -f Makefile.ref BUILD_OPT=1
+# $(MAKE) -C $(JS_SRC)/fdlibm -f Makefile.ref BUILD_OPT=1
+# $(MAKE) -C $(JS_SRC) -f Makefile.ref BUILD_OPT=1
$(GSMAKE) libespeak=yes
touch $@

@@ -38,8 +38,8 @@
dh_testdir
rm -f build-stamp
$(GSMAKE) clean
- $(MAKE) -C $(JS_SRC)/fdlibm -f Makefile.ref clean
- $(MAKE) -C $(JS_SRC) -f Makefile.ref clean
+# $(MAKE) -C $(JS_SRC)/fdlibm -f Makefile.ref clean
+# $(MAKE) -C $(JS_SRC) -f Makefile.ref clean
rm -rf oolite.app oolite.debug
rm -f http+_www.apple.com_DTDs_PropertyList-1.0.dtd
find $(JS_SRC) -name Linux_All_OPT.OBJ | xargs -r rm -rf



There is another point in the Makefile I don't solve for now :

SVNREVISION := $(shell svn info | grep Revision | cut -d ' ' -f 2)

My system don't speak english and the command : "svn info | grep Revision | cut -d ' ' -f 2" failed to return the good subversion revision. I don't still find a simple way to correct this so I've hard coded the revision number, I know, it's bad.
So now the packages are built and installed, so let do some play to test

Regards,
B.

PLAYING.TXT has been completely removed by the tree, indeed, and will not be returning.

The remaining changes are due to the fact that currently Linux does not build JS from source, and
statically links to a pre-built binary.
We are working on that... too!

Hello,

I've noticed the point about the javascipt engine. the libmozjs, provided by the system, is used at compile time. Is it a big problem ?

So, if I understand the way of how the build must be done, the javascript engine may be built as a static library and statically linked into the binary. Right ?

If I can help on this side don't hesitate.

Regards,
B.

What actually is needed is to have the js source built from within the oolite Makefile,
and not have a pre-built binary in the trunk. In case we need to build a debug oolite version then a debug js version should also be built.
This is how it used to be for the old js library.

Currently (in fact in a couple of hours) we use version 4.0b11

Feel free to give it a try. FYI the configuration options used for the pre-built lib are
../configure --enable-functiontimer --enable-trace-jscalls --enable-strip

Apologies for the Makefiles being slow to catch up to the new Javascript libraries, and the Debian scripts having gotten left behind during the recent code reshuffling. I've been suffering from a very bad case of RL.

We'll hopefully have a new set of Makefiles ready in a day or two which will fix the Debian package building as well.

Thank you for your kind informations.

Well, I've understood the picture.
It is a tricky case for debian packaging (policy) ... but I will try to make it work as expected.

Regards,
B.

Another option is to wait for a couple of days when this will be resolved in the trunk.
We are currently testing new Makefile scripts (bow before Micha) to resolve that.

Well,

I've studied in deep the different Makefiles, and it is a bit more clear for me now ... waow, I think I will wait the next makefiles to avoid discussing about points that are certainly knowned.

So welcome to JägerMonkey.
I've study the source package of iceweasel (firefox on debian), headache for all ! But the good new is the js library itself isn't difficult to package.
I'll certainly go to this way, as only this library will lack for building oolite on debian-based.

I've noticed that libpng14 is used for Linux build with deps; is it a requirement or libpng12 is sufficient for oolite ?

Have you study the case of using the js nitro engine from webkit project ?

Regards,
B.

McDjanoff wrote:

I've noticed that libpng14 is used for Linux build with deps; is it a requirement or libpng12 is sufficient for oolite ?

Oolite is supposed to build with libpng 1.2.x. I haven’t tested it for a while, but the changes required to support 1.4 were small.

McDjanoff wrote:

Have you study the case of using the js nitro engine from webkit project ?

It’s been suggested before, but it would require a complete rewrite of about a quarter of the game, and some existing OXP scripts would stop working. Almost any use of my time would be better than that.

Hello Supreme Grand Admiral,

Ahruman wrote:

McDjanoff wrote:

I've noticed that libpng14 is used for Linux build with deps; is it a requirement or libpng12 is sufficient for oolite ?

Oolite is supposed to build with libpng 1.2.x. I haven’t tested it for a while, but the changes required to support 1.4 were small.

It always a good new that you can use a dependance provided by the distro.

Ahruman wrote:

McDjanoff wrote:

Have you study the case of using the js nitro engine from webkit project ?

It’s been suggested before, but it would require a complete rewrite of about a quarter of the game, and some existing OXP scripts would stop working. Almost any use of my time would be better than that.

They are the best reasons to continue with *monkey js engine.

Thank you for your answers.

Regards,
B.

PS : The SpiderMonkey enhancement project wiki : JagerMonkey

https://wiki.mozilla.org/JaegerMonkey which indicate the Mercurial repository.

When building 'with deps' you are using non-distro dependencies, ie, the ones which have been pre-compiled and are shipped with the Oolite sources. This is mainly useful for the autopackaged versions of Oolite which cannot rely on a particular target system having the dependencies installed or even available.

The other benefit of using the included dependencies is that it avoids problems such as the GNUstep1.19.3 fiasco.

When building 'normally', only the Javascript library should be a non-system dependency, and this, with the new Makefiles (submitted today - many thanks to Getafix and another_commander for their revisions), gets downloaded and built automatically(*).

Hopefully one day we'll have a system-provided javascript library we can use as well.

Cheers,
- Micha.

(*) Download will fail if you are behind a proxy. You will need to run the update-mozilla.sh script manually. Any hints how to get the HTTP_PROXY environment variable through the make system into the update scripts much appreciated.

McDjanoff wrote:

PS : The SpiderMonkey enhancement project wiki : JagerMonkey

https://wiki.mozilla.org/JaegerMonkey which indicate the Mercurial repository.

If you look at the svn log, you should see that the js engine is updated to the latest jaegermonkey/spidermonkey release. the same engine on firefox 4 beta11 to be precise...

Micha wrote:

...the GNUstep1.19.3 fiasco...

Understatement!

Micha wrote:

When building 'with deps' you are using non-distro dependencies, ie, the ones which have been pre-compiled and are shipped with the Oolite sources. This is mainly useful for the autopackaged versions of Oolite which cannot rely on a particular target system having the dependencies installed or even available.

The other benefit of using the included dependencies is that it avoids problems such as the GNUstep1.19.3 fiasco.

When building 'normally', only the Javascript library should be a non-system dependency, and this, with the new Makefiles (submitted today - many thanks to Getafix and another_commander for their revisions), gets downloaded and built automatically(*).

Hopefully one day we'll have a system-provided javascript library we can use as well.

Cheers,
- Micha.

I understand your point of view and respect it, Misha, but, I am on the other side, the distribution one, which vision differ.
About dependancies problems, unfortunely, Oolite isn't the first project which is impacted by such thing. To solve this kind of problem I work at distribution's package level. I know that everybody can't do such thing, but it may be a solution some fellows may follow if they have a guide.

I still thinking that the js library must be on distro side, but many problems arise :

- You are using a library of a beta project which will not be included in the distros before some time.
- You are using a library of a project (firefox) which is tricky to package, so the time will certainly be more long than usual.
- Unfortunely, the library you are using isn't clearly separate from the main source of the project, in another word I don't know if JagerMonkey will evolve on is own and be merges to the main stream of Firefox, or evolve in the last one.
- You may encounter the risk of desynchronisation between distro implementation and your.

So, including this library in the source of Oolite is clever to build the whole project even in the worst situation.

But ( ), I recommand that the builder may have the choice to use the distro or third party built library by Makefile option.
I recommand also to indicate clearly dependancies in a text file (how to build ?).

I've appreciate every time to be able to build the debian packages.
The last word is still great thanks to all to have provided the wonderfull oolite.

Regards,
B.