Just to let you know - I have started to create build.xml for JOGL. I’m half way done for win32 - already running ant tasks and generating sources through GLEmitter, big items left are figuring out the mingw parameters to create DLL and adding jar creation routines.
I hope to finish it tomorrow evening - I’ll keep you informed.
Excellent. Thanks for taking this on. Please let us know how you progress and if you run into any problems. Feel free to contact me directly with questions and please email the Jogl project owners (of which I’m one) in addition to announcing it elsewhere if you complete it.
-Ken
http://nwn-j3d.sourceforge.net/jogl/
Download build.xml and local.xml and put into make directory. Edit local.xml to point to correct places (antlr jar library and jdk home). Type in ‘ant’, wait 2 minutes and look into build directory.
This is preliminary version of build file. Known problems:
[] only win32/mingw32 combo at the moment, absolutely NO support for other systems (but you can run makefile there)
[] a bit too eager to recompile files, I will need to check dependencies exactly
[] output too verbose in some places, not verbose enough in others; but we can add needed echos later
[] native code compilation is currently a bit hardcoded - some things should be moved to properties
[*] DLL DOESN’T WORK !!! I’m able to compile to object files and link dll, but it cannot resolve reference to jawt.dll on runtime - more on that below
I have taken jar files compiled with this ant file and run both Gears and Vertex demos with Mind2Machine dll with no problems. Unfortunately, every dll I have managed to build myself was failing with
java.lang.UnsatisfiedLinkError: JAWT_GetAWT0
Probably I’m missing something simple with build parameters, but I have hit dead end. For details, please check comment at end of build.xml file.
As you may note, I’m producing two jars here - jogl.jar and jogl-small.jar. They are 414, 312 kb long, -small one is without DebugGL and TraceGL classes. Probably doesn’t make sense in long run, but I wanted to check how big these two classes are in entire picture.
I have split build file into two parts - build.xml and local.xml. My idea is that user will never have to modify build.xml - all computer-related properties should go to local.xml. In CVS, I would image something like local-sample.xml instead, and .cvsignore for local.xml - so everybody can copy sample to local.xml and modify paramaters without signalling CVS outcoming changes.
Your turn now - I’ll not have time to play with it for next 20 hours, so if anybody can fix any of above problems (especially dll), please post a note here.
Instead of using an XML external entity why not use the property task with the file attribute. eg:
<property file="${user.home}/.jogl.properties"/>
<property file=".jogl.properties"/>
This allows the user to keep local settings in their home dir or it will pick up default settings from the current dir. It’s personally what I use for large projects that need local settings. You can find this pattern in a few different Jakarta projects.
what’s the diffrence between cygwin and mingw?
i have alway’s thought that cygwin is more closer to linux build env than mingw.
i got lot’s of warning when running build.xml,emission warning’s from antlr that is,should it build cleanly in antlr stage or is this know’n issue?
Below is a link to a ANT build and GlueGen ANT task that I was working on earlier this week. It is by no means finished but I thought that the GlueGen task might be helpful for people. Open in up within the jogl directory (it will put its files into “make” and “src”).
I wish that I had put this up sooner so that you didn’t burn any time getting traction with your own.
I am planning on finishing this up on monday. I will post another link then. I should point out that it will be win32 only but that it will be trivial to add other platforms.
I think it will be best if you will just copy/paste few extra items I have done (jar build, second phase compile, native compilation) to your build.xml and work from there, as gluegen task seems to be very nice solution.
I had an extra few minutes so I blew out the rest of the ANT build. You can dowload it at:
[url]http://www.realityinteractive.com/software/jogl.zip [/url]
Unzip it in your jogl directory.
I’m never one much for mixing concerns so I have left the native C building to the MakefileAnt. It is called from the ANT build so it’s transparent. For those of you interested in adding support for win32.gcc, just add an appropriate target in the ANT build and do the dirty deed in the MakefileAnt.
I have only tested it with the “win32.vc6” target and with that target I only tested the two demos. Since I build for SWT I haven’t tested this build against anything more robust.
I took a wack at the Linux build to get people started but don’t expect it to work out of the box.
I would hope that we can get this added to the JOGL CVS so that people can apply patches to it. Reality Interactive stakes no claim and extends no warranty on the provided source code. Put it under whatever license is appropriate.
Unfortunately, I cannot maintain this build moving forward as I need to branch and integrate it into my refactored JOGL for SWT.
I have added mingw32 build target. Here is a diff against original build.xml
http://nwn-j3d.sourceforge.net/jogl/build-rg.diff
and here full version
I was successful at building jogl using the win32.mingw option but the jogl.dll was placed in the /build directory and not /build/obj like in the win32.vc6 build.
I modified line 383 in build.xml to fix this
changed to
Also the JNI object files are being placed in build/obj but in the win32.vc6 build they were put into build/obj/jogl. I don’t know if this is a big issue since I was able to build the jogl.dll with no problems and I compiled and ran the Gears demo successfully.
-npbgreat effort … i just had the same ideas (ant based built process)
Artur,
Will your ant build work with cygwin? It’s important in cygwin to pass gcc the -mno-cygwin option if one doesn’t want the cygwin1.dll required. As I understand it, that option makes gcc under cygwin basically the same as the gcc from mingw.
I’m just asking to avoid having to install multiple C++ compilers.
[quote]Artur,
Will your ant build work with cygwin?
[/quote]
I have not tested it - I have basic cygwin environment installed, but without gcc. Last time I have played with cygwin it was version b18 and as far as I remember, it always required cygwin.dll (at least I had no idea how to disable it) - and from this time on, I use mingw.
Please try it - I have no idea if it will work out of the box.
Brief note to avoid duplicate effort: I am looking at the build.xml right now – thanks to rgrzywinski and abies for the initial file. However, it looks like it is going to need some work to work properly on Linux, Solaris, and Mac OS X. I also want to get rid of the dependence on the external MakefileAnt; if we’re going to do Ant-based builds then we’re going to get rid of all makefiles.
My personal preference would be an autoconf and automake environment. This would require cygwin, however, and I’m not sure how many people want to download all those tools. Personally, I can’t live without them. But I know I’m biased. It’s what I’m familiar with. I haven’t much experience with ant. After I start using it more regularly, I may change my opinion.
At the same time, if binaries are always available, then I would guess most people won’t bother making their own builds.
Please no autoconf or automake… I hate that stuff. I generally have nothing but bad experiences building stuff on unix (Linux) … those fancy auto configuring things always bail out because of some obscure error, regardless of the fact that you follow the build instructions to the letter. Ant has always been good to me… although that was for building only Java code.
As long as binaries are available I doubt most users will try to build the libraries themselves. Developers may dabble in it, but of course they will just use whatever is available to build things. Personally I kinda like antlr, but a pure ant make file would be “A Good Thing”.