And with vim and gusto, forth he went

[winston]

Vim the editor of course, and GUSTO - the Grand Unified Source Tree for Oolite (thanks whoever spotted that acronym - for once, this is *not* a backronym!)

Anywho, if you check out the 'cocoa-merge' branch (which was created before the term GUSTO was coined!) you can see what's happened so far. I was almost at this stage a couple of weeks ago when the wrong-plist-AI-bug was using up all my time, then I've kind of been lazy since. But I've worked on it some more since. To get the branch:

svn checkout http://svn.berlios.de/svnroot/repos/ool ... ocoa-merge

(or if you are an oolite developer, use the svn+ssh method so you can help fix it)

The branch is basically 1.62 (for Linux/BSD/Unix users, 1.62-3). Cocoa and Linux/BSD builds can be built out of it. A quick guide to the tree:

1. One aim was to make the source tree less flat so there isn't a big mush of source and other files all in the root directory - various files are separated out (this was partly the case under Linux anyway, the Resources were all in a separate subdir). So basically, under GUSTO you have the following folders:

Doc (nothing in there yet, but this will be where all documentation will live apart from the readme).
FreeDesktop: Files for GNOME and KDE desktop items
OSX-SDL: The SDL Xcode project (currently needs updating, it's not really a priority)
Oolite-importer: The Oolite importer, an OS X prerequisite build
Oolite.xcodeproj: The Xcode project to build Oolite for the Mac
Resources: AI, Config, shipdata etc. plists plus textures
autopackage: Autopackage for Linux (apspec files etc)
deps: Dependencies for all platforms
src: Source for all platforms

Drilling down a bit, src is subdivided further:
Core: Files that are built on all platforms
SDL: Files that are only built for SDL platforms
Cocoa: Files that are only built for the regular OS X Cocoa build

And deps:
Cocoa-deps: Mac OS X dependencies (Growl and Ogg Vorbis)
Linux-x86-deps: Dependencies for making Linux binary packages on x86

The deps directory is structured such for non OS X Unix binary builds (tarball packages for BSD, Irix, Linux etc.) are named Operatingsystem-CPUarch-deps. Therefore a script can work out which deps to package by running 'uname' to get the word 'Linux' or 'FreeBSD', and uname -p to get the CPU arch (i686 etc should be translated to x86). The idea is so that the same build script can make a binary package for any of the non-Cocoa platforms (XCode takes care of this for Cocoa).

Bugs:
Sigh. Xcode is doing some weird things for me. Even though I told it where the Ogg Vorbis stuff is it won't compile unless I copy the Ogg Vorbis folder to the top level. I also have to copy Oolite-info.plist to the top level. Perhaps I'm in denial about having to make the xcode proj from scratch (I took the existing one and just changed the paths).
I also get a couple of warnings which I can't track down (but that's probably just because it's been a long day at work already).

Also, I must have missed out a small merge somewhere because I get the oogui commander loader in windowed mode on OS X instead of the Cocoa file finder (except for the Load New Commander? question where the right thing is done). But this is trivial to put right.

Still left to do:
New package build scripts for non-Cocoa Unixes.
Updated documentation in Doc.
Giles has a bunch of graffle etc. files in the OS X repo at thor.acedragon.co.uk - should these live in GUSTO? (I assume these should continue to be under SVN. In which case a subdir for them will be created and they will be added.)


And of course... the Merge From Hell when it's time to branch merge all this back into the trunk (although I think I will trunk merge into the branch, I suspect this won't be easy to automate since so much stuff has moved around).

[Rxke]

(thanks whoever spotted that acronym - for once, this is *not* a backronym!).

Heh, that'd be me, and to be honest, I really thought it was a backronym!

[aegidian]

Giles has a bunch of graffle etc. files in the OS X repo at thor.acedragon.co.uk - should these live in GUSTO? (I assume these should continue to be under SVN. In which case a subdir for them will be created and they will be added.)

Yeah, these should be in the top level under 'Asset Source Files' or 'Resource Source Files'.

[winston]

Heh, that'd be me, and to be honest, I really thought it was a backronym!

It's just the way I wrote it - I could have quite as easily written 'the Oolite Grand Unified Source Tree' or something else, so you got lucky

[JensAyton]

I’ve fixed the XCode project. There were problems with the “Info.plist File” target setting as well as the various search paths.

[winston]

/me bangs head on the table.

Why didn't I think of looking in the damned file? Oh well, thanks

What was causing it to ignore the project settings for the path to the Ogg Vorbis stuff? That all looked right to me.
Anyway hopefully I'll get time this week/this weekend to do the Merge From Hell and make it the trunk (if not, next week) along with the Unix tarball packaging scripts.

[JensAyton]

The search paths were for $(SRCROOT)/Ogg Vorbis/, they should have been for "$(SRCROOT)/deps/Cocoa-deps/Ogg Vorbis" (with quotes). The Framework search paths setting was completely screwed upp (this happens easily). The Info.plist path setting didn’t specify the subdirectory.

While I quite like XCode, I miss the fact that in CodeWarrior, the files you put in the project are the files that will be used. :-)