Oolite Bulletins

Considering:
https://bb.oolite.space/viewtopic.php?t= ... adb6aea479

It struck me that much of the work needed to make sure of a compatible build environment for different gnu/linux distros would normally go in a configure script - then the install method would become -

1. get the source
2. cd into top directory
3. ./configure
4. make
5. make install

I.e. the standard gnu/linux install method.

The install target for make would put the program files someplace generic, like /usr/share/games, and put a launcher on the desktop.

With regards to configure - it's bad manners to suggest something to developers without providing code. So ... I was thinking something like this:

Code:

#! /bin/bash

#OOlite Configure Script
#Licence GNU GPL 2008
#www.aegidian.org

# run this script ./configure from the top level build directory.
# re: https://bb.oolite.space/viewtopic.php?t=4595

# also need files -
# jsautoconfig32.h
# jsautoconfig64.h
# GNUbuntu.postamble

#check location of top level makefile
LOC=`pwd`

#mke sure the addons directory exists
echo "checking runtime environment"
if [ -d ~/.Oolite ]
then
if [ -d ~/.Oolite/AddOns ]
then
echo "AddOns directory found - good"
else
echo "Creating AddOns directory"
mkdir ~/Oolite/AddOns;
fi
else
echo "Creating AddOns directory"
mkdir ~/.Oolite
mkdir ~/.Oolite/Addons;
fi

echo "checking build environment"
#Check for 64 bit, if not assume 32 bit
ARC=`uname -m`
if [[ $ARC == x86_64 ]]
then
echo "64 bit kernel detected"
cp jsautoconfig64.h cd deps/Cross-platform-deps/SpiderMonkey/js/src jsautoconfig.h
else
echo "32 bit kernel detected"
cp jsautoconfig32.h cd deps/Cross-platform-deps/SpiderMonkey/js/src jsautoconfig.h
fi

# the Makefile.ref entries below really need to be in the makefile
# the steps should be
# ./configure (sets the build environment)
# make (does the below)
# make install (does what make currently does)
echo "configuring spidermonkey javascript deps"
cd $LOC/deps/Cross-platform-deps/SpiderMonkey/js/src/fdlibm
make -f Makefile.ref
cd ..
make -f Makefile.ref
cd Linux_All_DBG.OBJ
mv libjs.so oldlibjs.so
cd $LOC
echo "done"

echo "configuring postamble"
cd $LOC
mv gnubuntu.postamble GNUmakefile.postamble
echo "done"

exit 0

# Still incomplete and a bit clunky
# need to account for non-ubuntu distros
# want a post-install to move the game files to /usr/share/games/ and put an
# icon on the desktop. Possibly make install should do that too.
[/code]

I know - needs work.
I have been deliberately opaque in the script so everything should be clear to a newbie to scripting. If a regex master wants to obfusticate the code in the name of brevity, be my guest ;)

The above should handle the ubuntu install.
Really need this to be less platform dependent, and include tests for the required dependencies too. Also should not really assume that anything not x86_64 is 32 bit. But it's a start.

What say ye?

I'm now stalking you on the boards!

I've had Oolite installed on XP and Fiesty and now Gutsy - there is a thread somewhere to get it to install relatively pain-free under Linux (although I did have some issues with Gutsy with gnustep (I think not being installed properly). However anything which makes it happen easily/automatically certainly gets my vote!

The ubuntu install method is in the link at the top of the first post. It was tricky to find so I guess it needs more mention.

The ideal for ubuntu would be to create a deb + repo for 1.7 ... need to learn. But there is a reason that source installs now all have that configure step - and you are looking at it.

Note - I have no way to test that script on 64 bit. I may be able to test on other nixes though. The script needs three specially created files to work - they can be created from information in the link...

Note - I was having trouble with full-screen in Ubuntu 8.04 --- disabled compiz and it's fine. I have no idea what is causing this but it looks like something (in compiz) is updating and interfering.

As I'm a fan of "if it ain't broke don't fix it" I'm sticking with Gutsy until I build a new machine from scratch and then I'll probably put Gutsy and Hardy on it (simply for the LTS of Hardy)

Well sure - but I'm talking about the linux build process and the Ubuntu releases are peripheral to that. There are special forums for talking about linux, you'll find me there too.

For just Ubuntu - a patch may be easier. Then the Ubuntu build process would become:

get source + deps
apply patch
make

It's just that the configure file method is more inclusive.

I also forgot the ~/.bashrc modification... note, for Ubuntu, the GNUstep.sh location has changed recently. So I need to add a line for Note: this script goes in the source.
Where do source submissions go?

Simon B wrote:

Note: this script goes in the source.
Where do source submissions go?

Either someone will pick it up from here or you can make it a feature request here and that way it'll be tracked:
http://developer.berlios.de/feature/?group_id=3577

Micha wrote:

Simon B wrote:

Note: this script goes in the source.
Where do source submissions go?

Either someone will pick it up from here or you can make it a feature request here and that way it'll be tracked:
http://developer.berlios.de/feature/?group_id=3577

Attempted secure login - firefox returned:

Secure Connection Failed
developer.berlios.de uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)

So much for feature request - though I did manage to verify that there were no outstanding requests like this.

Simon B wrote:

Attempted secure login - firefox returned:

Secure Connection Failed
developer.berlios.de uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)

So much for feature request - though I did manage to verify that there were no outstanding requests like this.

Yes, I know that as well from BerliOS. Doesn't firefox allow you to proceed anyway and decide yourself to trust the certificate? Other browsers do, and that's what I did when I first surfed on BerliOS. (Next thing you would have to do is to create an account, of course, before you submit anything.)

Actually I've been meaning to ask - is there any way to get at the root certificate for BerliOS? Be nice to just install & trust 1 certificate instead of several.. I've searched a bit but couldn't find it.

Simon B wrote:

5. make install

That bit should really be done by running the autopackage (so run makeinstaller, then run the resulting oolite-x.xx.package file). The advantage of using the autopackage is that it gets the game added to the Games menu and makes an uninstaller, too. The autopackage is the normal method of distributing the distro independent binary gets tested when you run it.

Autopackage works fine with the GNU autoconfigure stuff, but I'm not sure how well the GNUstep make stuff works with autoconfigure.

winston wrote:

Simon B wrote:

5. make install

That bit should really be done by running the autopackage ...

How does autopackage fair with heavily managed distros like Ubuntu?

Still... fair comment.

I still think that the make -f lines are properly run from the makefile in the event that linux is detected... i.e. the config script is run. I don't know about the win build process.

config should deal with checking and setting up the build environment. Missing dependencies should cause it to exit with an error, listing all the missing components rather than attempting to install them. Then loading the correct header.

I would like to know about variations to the ubuntu source install method when compiling in different distros - would linux users please declair their distro + release? Thank you.

If all I know about ends up being Ubuntu, I may as well just make a deb.

Ubuntu Fiesty 7.04 and Gutsy 7.10, new build in Xmas break will be 8.04 Hardy...

Simon B wrote:

How does autopackage fair with heavily managed distros like Ubuntu?

Absolutely perfectly. Autopackage is designed to co-exist and not interfere with the system packager.

However, since Ubuntu is the most popular desktop distribution, really there ought to be the scripts et al. to create .deb files in SVN (especially as 1.65 is part of Ubuntu, I suspect it would be nice for Ubuntu users to be able to get updates with the normal update manager).

Ubuntu build scripts are in the trunk now.