Unfortunately in some cases things are just a bit more complicated.
- First of all, the JarBundler app doesn't provide command-line or automated usage, so creating the app for every release quickly becomes tedious. To solve that problem Seth Moratibo provides the wonderful JarBundler Ant Task.
- Second, native dependencies are more difficult to stuff into your app. Sure, JarBundler (both Mac's and Seth Moratibo's) allows you to add the dylibs as "Additional Files and Resources," but that only works in the simple case. If your dylib dependency has another dylib it relies on, you're out of luck. When one dylib tries to call the other, the dynamic linker is ignorant of the directory containing the second dylib.
Not to worry, there's a quick fix. Changing your working directory to the folder containing the dylibs solves the problem, since the dynamic linker always looks in the current directory. But how do you refer to the current directory?
<!-- Bundle jar into .app. -->In that task, libpenntotalrecall relies on libfmodex at runtime. Be sure the Ant JarBundler jar is in a directory called buildtools.
<target name="package_mac_app"
depends="package_jar, compile_native"
description="bundle the runnable jar into a Mac Application">
<taskdef name="jarbundler"
classname="net.sourceforge.jarbundler.JarBundler"
classpathref="buildtools"/>
<echo message="CREATING MAC .app EXECUTABLE"/>
<jarbundler
dir="dist"
name="PennTotalRecall"
mainclass="control.Start"
icon="icons/headphones.icns"
jvmversion="1.5+"
infostring="Penn TotalRecall"
shortname="TotalRecall"
bundleid="edu.upenn.cis.memory.totalrecall"
jar="dist/PennTotalRecall.jar"
workingdirectory="$JAVAROOT">
<javafilelist dir="dylibs" files="libpenntotalrecall.dylib"/>
<javafilelist dir="dylibs" files="libfmodex.dylib"/>
</jarbundler>
</target>
No comments:
Post a Comment