Porting (to MacOS X) work...

[DCoder]

So, is it safe to say that the only implementation-specific code lives in these 9 files:

org_lwjgl_Display.cpp
org_lwjgl_opengl_BaseGL.cpp
org_lwjgl_input_Controller.cpp
org_lwjgl_opengl_Pbuffer.cpp
org_lwjgl_input_Cursor.cpp
org_lwjgl_Sys.cpp
org_lwjgl_input_Keyboard.cpp
org_lwjgl_Window.cpp
org_lwjgl_input_Mouse.cpp

?

Under the native/macos tree, I find 6 of these (Display, BaseGL, Keyboard, Sys, Mouse, Window). To what degree they are complete or "bug-free", I do not yet know. I am hoping that I can reconstruct a functional build (ide project) over the weekend and determine the level of completeness of these implementatons.

In an effort to work the immediate problem, I have put my efforts of enhancing the autoconf setup to support OS X on hold for the time being. If I am going to stick to this project however, I am absolutely determined to make sure that the autoconf stuff be able to support *every* build platform that it can (cygwin, linux, *bsd, *nix, darwin, etc). I believe that, more than anything else, will ensure that this project is embraced by non-Windows developers. As a peripheral comment, I hope I'm not too presumptuous in saying that I think the SDL project has done an excellent job in tackling both the problems of architecture dependence and build construction -- it may be worth exploring (elias?).

Of course, I am still *quite* under water when it comes to trying to understand the JNI. It looks like most of it is just pass-through boilerplate to the subsystems (true?). I'm hoping that all of that (except the 9 arch-dependent files listed above) is already implemented in an arch-neutral sort of way, and I shouldn't have to worry about it. (Right?)

Heck, just as a wacko, crazy-kid idea, would it be plausible or even desirable to use SDL as the graphics boundary layer? It already has GL hooks, and off-loading the cross-platform work to that project might be worthwhile... Like I said, though, that may just be me talking crazy-talk.

Anyway, more later. I go to read code (Gawd, how I hate c++).

-daniel

[elias]

You're almost right about the platform specific 9 files - only 6 have been ported to macosx because Pbuffers, Cursor and Controller can be considered the least important features. However there's some platform specific bits even in the platform common files, like how to dynamicly load a native lib (extal.c and extgl.c).

Regarding the build system - yes, it sucks and it's because the autoconf maintainer is currently not active in the project, and I haven't got time to really take care of it yet. It would be of tremendous help to make it work with any platform. And you're perfectly entitled to bring the SDL build system forward as a good example.

Regarding SDL - I have a warm feeling about using it to offload some of the more tedious chores of lwjgl. Like the build system and OpenGL window system code. The big thing that is stopping me is the added size of a lwjgl distribution. SDL is rarely installed per default on win32 and would have to be bundled like OAL is right now.

Glad to have you on board btw! And keep those questions coming. And do use IM to contact me if you like.

- elias

[DCoder]

Well, I'm currently dead in the water. For some completely unexplainable reason, it appears as though I decided to test a "developer preview" of the latest shipping 1.4 version of the JDK that Apple's working on.

And it's totally sunk me. The update has apparently left me without working jni headers. I'm hunting around the mailing list archives for Apple's java-dev list to see what the deal is.

According to the docs for the update, to restore original functionality of any JDK (1.3 _OR_ 1.4) I will have to reinstall my system from the ground-up and that's just not going to happen.

Hopefully those on the mailing list will have some insight into this issue.

-daniel

[princec]

Suckage.
Which headers?
The non-platform specific jni.h headers are common across all implementations I believe.

Cas

[DCoder]

!! !!

Yay! I've gotten a project created in the IDE and I'm in the process of working out the kinks of the build.

More as it develops (pun definitely intended).

-daniel

[princec]

Wow, excellent!
Remember you can test it on Alien Flux if you need a thorough test And Matzon's got all those JNLP tests up on the sourceforge website too for unit testing.

Cas

[elias]

What about the cvs changes we are in the middle of? CVS version should not be able to compile correctly when Matzon's OAL are missing...

- elias

[DCoder]

What about the cvs changes we are in the middle of? CVS version should not be able to compile correctly when Matzon's OAL are missing...

I didn't say I had a full build yet. I didn't know that the CVS build was broken. Is that true? I did build a linux system just a few days ago.

Right now I'm just trying to get the IDE configured with the proper DEFINEs so that my compiler's not complaining about stuff it shouldn't be (like _WIN32 things).

Ironically, things are breaking in the extal.h area at the moment. I noticed that the structs ALCdevice & ALCcontext are defined in alctypes.h _and_ extal.h, but the declarations are wrapped in all sorts of preprocessor goo that is pretty arcane to me (I'm not all that up on my C preprocessor language). Not to mention that in alctypes.h, ALCdevice is defined as an _AL_device and in extal.h it's defined as a ALCdevice_struct.

Is this the code that's in a state of flux at the moment? If so, when can I plan on it getting a little more cohesive? I know everyone's probably got a lot of stuff going on (so do I). I just want to be able to plan a little bit better around this, if it's really an issue.

-daniel

[elias]

Oh - the native libs will probably compile, because they don't care if they have ints or jobjects as pointers. It was the examples and the lwjgl jar I meant.

- elias

[DCoder]

Oh - the native libs will probably compile, because they don't care if they have ints or jobjects as pointers.

Ah, okay. Then the build problems I'm having are purely mine. Cool.