OSX need help

[Athomas Goldberg]

killer!   Let me know when you've updated CVS

BTW: I now owe you several drinks....

[Athomas Goldberg]

Okay. Merged build file is in CVS. Once you've got it working be sure to post the OSX Status to the forum. Thanks again.

[gregorypierce]

Made a slight change to the build file.

1   2   3   4   5   6   7   8

<condition property="isUnix">           <and>                   <os family="unix" />                   <not>                         <os family="mac" />                   </not>             </and>     </condition>

You have to do this or else isUnix is still true as OSX qualifies as os family Unix. I've checked this change into CVS and everything seems to be building fine and all of the tests run successfully.

Games published by our own members! Check 'em out!

[Athomas Goldberg]

Greg --

Could you go ahead and update the README.txt in JOAL with the build requirements? Once you've done that I'll add that info to the JOAL homepage. Thanks

[swpalmer]

I just grabbed the latest from CVS but it doesn't come close to building for me (OS X 10.3.1  JRE 1.4.2 DP 1)

I get:

/Users/scottpalmer/dev/joal% ant
Buildfile: build.xml

init:

native-compile:

init:

compile-so:

compile-dll:

compile-jnilib:
    [echo] Compiling shared library for OSX

compile-native-lib:
    [echo] gcc -Ic:/j2sdk1.4.2/include -IC:/Program Files/Creative Labs/OpenAL 1.0 SDK/Headers -O3 -D_AGL -bundle  -o ../../lib/libjoal.jnilib common_tools.c extal.c eaxfactory.c eaxbind.c alfactory.c alcbind.c albind.c
    [exec] gcc: Files/Creative: No such file or directory
    [exec] gcc: Labs/OpenAL: No such file or directory
    [exec] gcc: 1.0: No such file or directory
    [exec] gcc: SDK/Headers: No such file or directory
    [exec] In file included from common_tools.c:40:
    [exec] common_tools.h:43:17: jni.h: No such file or directory
    [exec] In file included from common_tools.c:40:
    [exec] common_tools.h:61: error: parse error before '*' token
...

It continues downhill from there...

Obviously it is still trying to use Windows stuff.

[gregorypierce]

Done. I've updated README.txt and updated CVS.

[gregorypierce]

Yeah, because you didn't change the bits in build.xml that say "change to taste". you will need to specify a few paths as the build.xml for JOAL is not as generic as that for JOGL.

Read the README.txt.

[swpalmer]

Ok, I know it won't solve 100% of the issues.. but rather than hardcode platform specific paths in the build file, lets use the same platform detection rules and hardcode typical paths for each platform.

For OS X this would be:

   <property name="jdk.home" value="/Library/Java/Home"/>
   <property name="openal.home" value="/Library/Frameworks/OpenAL.framework"/>

Although G.P. says that sometimes OpenAL might go elsewhere, this is where the installer form the creative site put it for me.. it doesn't give a choice.

I also had trouble building (complaints about finding assertFalse) because I had a more recent build of junit.jar in my class path.

Once I cleared that up 'ant runtests' worked fine.  It would be great if we can get rid of those duplicate definition warnings though.

[Athomas Goldberg]

Ok, I know it won't solve 100% of the issues.. but rather than hardcode platform specific paths in the build file, lets use the same platform detection rules and hardcode typical paths for each platform.

For OS X this would be:

   <property name="jdk.home" value="/Library/Java/Home"/>
   <property name="openal.home" value="/Library/Frameworks/OpenAL.framework"/>

Although G.P. says that sometimes OpenAL might go elsewhere, this is where the installer form the creative site put it for me.. it doesn't give a choice.

I also had trouble building (complaints about finding assertFalse) because I had a more recent build of junit.jar in my class path.

Once I cleared that up 'ant runtests' worked fine.  It would be great if we can get rid of those duplicate definition warnings though.

I'm considering this. In the meantime, I've commented out the jdk.home and openal.home properties in the build file, added a ALL CAPS message indicating that they must be set and uncommented, and added a <fail> task to the <init> target which will cause the build to fail if jdk.home and openal.home are not set, iinforming the user to see README.txt for instructions.  Hopefully this will reduce frustration for folks until a better solution presents itself.

[swpalmer]

Perhaps you can set the properties to reasonable defaults AND test that such folders exist... THEN spew the configuration message if they don't.    Maybe you can also mention the path issue if the build fails in general.

It would be best if it "just works" and custom setup steps can be avoided.

*edit*
Doesn't Ant need to know the JDK home anyway?  Can't we get that path from Ant so it doesn't need to be specified on a per-project basis?

Games published by our own members! Check 'em out!

[Athomas Goldberg]

Yeah, I'll look at that again. When I first set up the build file way back when there was some strange reason why I needed to set it, but I can probably go back and fix that now. Don't know how we can avoid the openal.home property yet, but we may at least be able to specify the default locations, check if they're valid and then fail if they aren't.

[gregorypierce]

Well on OSX I've discovered that we have to make sure that the framework is always installed into this location regardless as the call to NSAddImage requires an absolute definition to the framework's library. As such we can specify that OpenAL on OSX HAS to be installed to this location. Otherwise we'd have to actually change the code in ALFactory.

[Athomas Goldberg]

Doesn't Ant need to know the JDK home anyway?  Can't we get that path from Ant so it doesn't need to be specified on a per-project basis?

Yeah, ant looks at the JAVA_HOME environment variable, so I've changed it so that jdk.home references JAVA_HOME by default.  I'm going to look at setting the openal.home to common default values for each platform and then testing to see if these defaults are actually valid. Gotta do a little more reading up on ant first.

[Athomas Goldberg]

I just checked in a new version of build.xml that checks for an OpenAL installation in a default location for each platform and then fails if can't find it.

I set the defaults according to the README. I've only tested it on Windows, where it appears to work fine. If OSX and Linux folks can test it on their respective platoforms, and adjust as necessary, I'd greatly appreciate it.

[gregorypierce]

OSX is clean. Just typing ant where the build.xml is works and builds things correctly.

[swpalmer]

Cool.  I have one more nit-pick though

Rather than modifying the build file to set these paths wouldn't it be better to override the defaults by passing the path as a property to ant on the command line.

Since the build file is in CVS it seems "unclean" to have people make local changes to it.

e.g. we could use
ant -Dopenal.home=blah

Or maybe better, have a property file that can be edited for the system that is not part of CVS but overrides the properties in the build file if present.

ant -propertyfile mydefs.properties

There is also the option of using the ANT_OPTS or ANT_ARGS environment variables.

Like I said - it's a nit pick.  I think it will make things a little bit cleaner, but what we have now is working well too.

If there are other paths like this that need to be set for the other core projects (JOGL, JInput) it would be nice to standardize on the method of specifying them.  Consistency makes things easier to deal with. Maybe we should be looking at some other projects to see what they do. (unless they say to modify the build.xml )