Ok… so I grabbed the latest source from CVS and built it on my Powerbook.
… that seemed to work… minor rant - I HATE config scripts. I can’t imagine that they are useful. Specially for relatively simple bindings like LWJGL. I mean really, why check to see how long the command line arguments can be (65535), or if I have some header file that is never used by the project.
Anyway… after tolerating the non-standard build output (*.lo ???) I can’t seem to find the JNI lib anywhere.
What’s the trick?
Ther “config scripts” are shoddy but at least they’re somewhat standard, because it’s the same scripts we use for linux. Most of the tests are simply builtin, with no apparent way of disabling them. Anyway, if the build succeeded, the lib should be in native/.libs/liblwjgl.something (can’t remember). It might need a run through ‘strip’ to trim down the size.
My complaint about config scripts has nothing to do with them being standard or not - it has to do with the fact that they don’t seem to do anything useful and are therefor an added complication that I could do without. But that’s just a minor peeve… I don’t really care about it so long as it works.
The build script does run ‘strip’.
Why is the library built to a hidden folder?
Why doesn’t the name follow the convention for naming a JNI Library on the Mac?
(e.g. for System.loadLibrary(“X”); the file must be named “libX.jnilib”)
The only outputs in /src/native/.lib (note already how we are in the “src” folder and the files there are NOT “source”, sigh…) are:
Scotts-Laptop:~/dev/LWJGL/src/native scottpalmer$ ls -l .libs/
total 11696
lrwxr-xr-x 1 scottpal scottpal 10 7 Jun 11:53 liblwjgl -> liblwjgl.0
-rw-r–r-- 1 scottpal scottpal 5971088 7 Jun 11:53 liblwjgl.0
lrwxr-xr-x 1 scottpal scottpal 10 7 Jun 11:53 liblwjgl.0.0.0 -> liblwjgl.0
lrwxr-xr-x 1 scottpal scottpal 14 7 Jun 11:53 liblwjgl.la -> …/liblwjgl.la
-rw-r–r-- 1 scottpal scottpal 683 7 Jun 11:53 liblwjgl.lai
Yuk. None of these are named correctly for a JNI lib (on Mac or Linux). The main file is huge - has LWJGL really grown to over 5 MB? The last version I had that works with AlienFlux is about 640k (that ought to be enough for anybody :))
Again, the hidden directory is part of the standard nature of the system. I don’t have the time or patience to make it behave any better, I’m afraid. But I agree with you on most terms. You have to use the .0 version of the file, and you have to use a more persuasive version of strip to make it smaller. something like strip -X or -S can’t remember what exactly. I’ve been unable to find out why even the stripped lib is so large (should be around 6-800k), where the other platforms have a file size of 2-300k.
Ah, good old libtool. What a mess…
Anyone who can cajole libtool into doing what they want deserves a medal, in my opinion. Unless it’s really improved over the last few years, that is.
Well unfortunately I haven’t got the time or patience for it either. 
I was hoping to just have to run ‘ant’ and have everything just work. Ant only builds the Java side of things. It could detect the platform and execute the command line needed to build the native side. The JOGL builds are set up that way, so maybe you can borrow some ant code.
We would actually prefer if you created an Xcode project to do the whole thing and checked it in to the platform_build directory, as that’s what most MacOS developers are going to be using.
With that obstacle out of the way a lot of Mac devs might be able to help out but it really is a huge hurdle not just being able to check it out and build it.
Cas 
I will take a crack at getting at least an XCode project done. It would be ideal if the project could be built from the ant script as well. But since the build isn’t doing that as it is I’ll take it one step at a time.
Do you feel like having a stab rewriting it all to work in Cocoa? (And also please note we have nothing against you delegating Window creation and screen mode trickery to AWT if you like).
Cas
I’ve been thinking about that actually… I still have a few more chapters to go before I am a Cocoa expert and I suspect it will take a significant amount of playing around after that… The major problem being that I’m a complete newbie in terms of actually programming OpenGL… I just haven’t had the time or a relevant project to sit down and actually DO some OpenGL programming.
But I do agree that a Cocoa port is very likely the right direction to go in. A Java application on OS X is a Cocoa application (for JRE 1.4.x) so it seems only natural that if you want to play nice with the JRE that you are talking the same language.
I don’t want to commit to anything major like that now though… I’ve already NOT helped out a lot more than I was hoping on a few Mac ports… finding the time has been difficult. By the time I get back to it things have moved ahead a lot without me and I’m back to square one.
I will get LWJGL building in XCode… then take a stab a ruidimentary Cocoa-ization… but that may not go so smooth
FMOD stuff is a bit of a pain.
“fmoddyn.h” is not part of the fmod SDK for Mac
fMOD_INSTANCE is not defined in the fmod headers in the fmod SDK for Mac
I downloaded fmod 3.73 for Mac.
There are no methods in fmod that start with FMOD_… as far as I can see. only FSOUND_… and FMUSIC_…
What am I missing?
[quote]FMOD stuff is a bit of a pain.
What am I missing?
[/quote]
For now, you really should exclude FMOD (it’s an optional API and not part of the core). I am aware about macs, and the lack of a dynamic header. However I need to find some sparetime to investigate it thoroughly - at which point I can just message you to add FMOD to the build system.
ok. no FMOD for now.
Am I correct in assuming the stuff in the altivec folder is not actually used?
Oh, and did you want the XCode project to build both the java and the native bits? I’m starting with just the native bits - so you run the ant build and that generates all the headers that are referenced in the XCode project. I’ve started with the project template for a “Java JNI Application” so extending it to build the whole thing shouldn’t be hard. XCode takes some getting used to though - I never use it for Java projects, I prefer Eclipse.
Just the native bits.
Cas
All hail Swpalmer - the fountain of Cocoa knowledge as we know it! ;D
Let me know if you would like to test any code developments on my apple system.