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.
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.
[quote]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?
[/quote]
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.
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.
OSX is clean. Just typing ant where the build.xml is works and builds things correctly.
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 )