Oolite on Solaris

drew · Post by **drew** » Tue Aug 01, 2006 6:34 pm

Not Linux I know...

Don't know if anyone else is interested in Solaris, but since I work for Sun Microsystems at the moment I thought I'd try to get Oolite working on here.

Doesn't natively of course (Sparc chip architecture), but I was able to run it on an x86 box with Solaris 10 and the optional Project Janus once I mucked about with the X config and got all the gnustep stuff for Solaris.

Just curiousity I guess, I'm presuming with the source code I could compile for Sparc Solaris and play natively on my workstation?

Cheers,

Drew.

JensAyton · Post by **JensAyton** » Tue Aug 01, 2006 7:01 pm

Should be possible.

eddyp · Post by **eddyp** » Wed Aug 02, 2006 9:33 am

You will need an Objectual C compiler (GNU maybe?), GNUstep base, SDL and SDL mixer libraries, and that should be enough for compilation.

If you have those, it should be enough to be able to compile the source and give the program a go on Sparc.

Get the -src and -data packages compile te source, add the data in place (I think Resources directory) and try to start the game.

Post by **dajt** » Wed Aug 02, 2006 10:37 am

You also need SDL_image.

When I used to build it on linux I would get the latest version of GCC, binutils, and make and build them all into a directory in my home directory which I'd put at the front of the path. Then I didn't have to worry about what was already installed.

Then I'd get and build GNUstep. Then the SDL libraries.

You don't need most of GNUstep, just gnustep-base, so if the gui part of it gives you grief don't worry too much because you won't need it. It might still work to compile without sound (you'll see the obvious flag in the makefile) if SDL_mixer doesn't want to compile.

Someone (ie not me ;) should make a dir structure that contains all the required source from GNUstep and a makefile to compile it along with the Oolite source so we can get rid of the absurdly opaque build system and masses of junk that come with it.

eddyp · Post by **eddyp** » Wed Aug 02, 2006 11:14 am

dajt wrote:
Someone (ie not me should make a dir structure that contains all the required source from GNUstep and a makefile to compile it along with the Oolite source so we can get rid of the absurdly opaque build system and masses of junk that come with it.

I am sorry, but I don't agree with you, shared libraries have a purpose of their own. The README should contain that information, as it did before 1.65. (BTW, after the GUSTO, the README does no longer contain useful information regarding compilation and dependencies - a regression, IMHO.

Post by **winston** » Wed Aug 02, 2006 11:57 am

On Solaris: I think there's a site out there (I've not used it in a long time - I now run OpenBSD on my Sparc box) with recent Solaris packages for most GNU stuff. I'm sure Google will provide!

I'm not sure the build process is "absurdly opaque" - so long as you have the dependencies it's merely a matter of typing "make", and the Makefiles are simple enough for even me to understand. Dependencies aren't part of the build process! Those with the programming skills to be able to modify Oolite's code probably also have the skills to download and install the dependencies (which are documented in the wiki). Those who just want the latest bleeding edge SVN output - that's what the automatic nightly build is for - there's no need to be a developer if all you want to do is run the newest code.

Post by **dajt** » Wed Aug 02, 2006 11:09 pm

OK, seems I'm the only one who hates GNUstep enough to want to get rid of it. Lucky I didn't make a start on that one.

The build process is opaque and inflexible. As far as I can see, GNUstep doesn't allow for Obj-C++, which most of you won't care about but which I'd like to have. It took me longer than I wanted to spend on it to find out where the compiler to invoke was set, but maybe I'm just dumb.

Still, what we have works and if everyone else is happy, I'm happy to leave it as-is. Windows users don't have access to nightly builds because no-one has seen fit to put the processes in place.

Post by **winston** » Thu Aug 03, 2006 9:46 am

Well, the ObjC++ thing will likely be a Makefile issue (GNUstep makefiles are really just standard makefiles with a bunch of extra macros - anything you can do in a normal makefile you can do with one for a GNUstep project). If you don't grok make then it does look opaque and inflexible. Don't worry - I don't grok make either, and it looks pretty opaque to me! But I' know people who do and what they can do with make would make your wossnames spin. Make is definitely NOT inflexible - it is extremely powerful, and I've seen what some people can do with it. It's definitely NOT opaque when you learn it thorougly either, because I've seen people work with Make with the ease I can write a "Hello World" program in Perl.

Objective C looks pretty opaque and inflexible unless you understand Objective C, too.

Getting rid of GNUstep is fine by me, but I don't think you will find a replacement for GNUstep Base (which I think works pretty well). I was quite glad to see the back of GNUstep GUI and Back which caused nothing but problems (and THANK YOU for all the hard work with SDL, which was the *major* part of expunging that awkward code) - however, I quite like GNUstep Base. Writing an Objective C library from scratch that is compatible with Cocoa's Foundation (which is what GNUstep Base provides) is a task probably a dozen orders of magnitude harder than becoming a Makefile Wizard. It's probably why the early porting attempts (convert ObjC to C++ for a Windows build) failed and the guy vanished: he probably realised that now he had a converted C++ source, he was now going to spend the next 4 years of his life writing Cocoa's Foundation in C++!

I would have put a Windows nightly build in place when I did the Linux one, but that requires me to have a Windows server in a datacentre somewhere *just* to compile Oolite, and having a dedicated server just to do nightly builds would be very expensive! (Even if I hosted it at home, since I'd have to buy another computer and power it). The nightly build server for Oolite-Linux was already there, and is already earning money by providing web space and shell accounts, and setting up a cron job on an already paid for and extant server was easy and didn't cost anything apart from a few minutes setting up some tools.

However, now VMWare Server is out of beta and is a free (as in beer) product, I might still do it since I have an unused (and perfectly legal) copy of XP doing nothing, which could be uploaded in a VMware machine to one of my Linux servers. It's just a matter of finding the time to set everything up.

Post by **dajt** » Thu Aug 03, 2006 12:38 pm

I wasn't suggesting we get rid of the gnustep-base library, with all the NS* classes, but just to treat it and its includes like any other dependency (eg the SDL libs).

I guess it sort of is like that already. But there seems to be so much bumph under $GNUSTEP_ROOT it really gets on my nerves.

Post by **winston** » Thu Aug 03, 2006 2:13 pm

I bet the GNUstep development can be cleaned up in the way that the bits needed for run time were cleaned up (especially as Oolite is now compiled as a basic Objective-C program rather than a GNUstep application). Perhaps I ought to look into using just a bog-standard Makefile (at the end of the day, to get the right Obj-C stuff for Oolite you've just got to be able to find the NS* header files and the libraries). I probably ought to learn Make better in any case.

I've been mulling over the suggestion of an archive with everything needed to develop - a Developer's Kit Of Last Resort if you like, which makes all the less common dependencies to make porting to other Unix-like platforms a bit easier. It might make a good winter project.

JensAyton · Post by **JensAyton** » Thu Aug 03, 2006 2:42 pm

winston wrote:
Getting rid of GNUstep is fine by me, but I don't think you will find a replacement for GNUstep Base (which I think works pretty well).

LibFoundation. Unfortunately there seem to be about 37 different versions with different feature sets implemented, and quite possibly none with all Oolite needs. But if you really want to get rid of GNUstep dependecy, that’s where to start.

Oh, and I’m quite interested in ObjC++. It’s not about makefiles. It’s about compiler support. According to what dajt has posted elsewhere, the GNUstep version of gcc doesn’t have C++ support compiled in, and ObjC++ (i.e., the combination of both in one file) requires gcc 4.1 (or of course apple-gcc).

Post by **winston** » Thu Aug 03, 2006 3:04 pm

What is this GNUstep gcc of which people speak? I've never used it - I've always used the compiler that came with my Linux distro (i.e. gcc 4.1.1 in the case of Fedora Core, gcc 3.6 in the case of Debian).

Is this a separate compiler, and/or is this referring to something that comes with the Windows GNUstep distribution?

magamo · Post by **magamo** » Thu Aug 03, 2006 4:16 pm

I suspect that it's something that comes with the Windows GNUstep distribution. The Unix GNUstep build process does NOT make its own compiler. (There weren't any GNUstep packages for Slackware that I found, so I rolled my own yesterday) It seems curious that the Windows version of GNUstep would come with one, unless it was a full developers set, which included just gcc and gcc-objc, in that case, I'd assume that you could swap out a full mingw distro for it.

Post by **dajt** » Thu Aug 03, 2006 9:52 pm

winston wrote:
What is this GNUstep gcc of which people speak? I've never used it - I've always used the compiler that came with my Linux distro (i.e. gcc 4.1.1 in the case of Fedora Core, gcc 3.6 in the case of Debian).

Is this a separate compiler, and/or is this referring to something that comes with the Windows GNUstep distribution?

Because GNUstep is meant to be built in a POSIX-like environment, which is nothing like Windows, the Windows distribution comes with a POSIX-like environment called MSYS/MinGW. MSYS contains all the usual commands like ls, sh, find, etc, while MinGW is GCC compiled for Win32. It's like cygwin, but different.

The versions of GCC in all MinGW distributions and that comes with GNUstep is pretty old, and the one that comes with GNUstep only has the C and ObjC front ends built for it.

So to get C++ going I had to build a new version of GCC from scratch and make sure it was found before the one that comes with GNUstep.