Boost logo

Boost-Build :

Subject: Re: [Boost-build] Problem with notfile target
From: Ian Emmons (iemmons_at_[hidden])
Date: 2008-12-01 14:34:09

I have successfully gotten my jam file to work to an acceptable
level. (My Jam file is listed below.) My lib target now declares a
dependency on a file called "Parliament.jar", and I have replaced the
notfile target with a make target for this file. The make target's
action invokes an ant script, which compiles a bunch of Java sources,
archives them into the file Parliament.jar, and then invokes the javah
tool to generate the JNI header files that are included by the lib
target's sources. This has a few anomalies, which I can live with, at
least for now:

(1) If any of the Java sources change, then all of the lib sources are
rebuilt, even though only a few of them depend on the JNI headers.
This is because I am using the jar file as a proxy for the actual JNI
headers in the dependencies. Ideally, the jar file would be an
internal detail of the ant script that the jam file would never see,
and the dependencies would be tracked in the jam file through the JNI
header files themselves. Unfortunately, I have not found a simple way
to declare a rule that takes N source files (the Java sources) and
produces M target files (the JNI headers) where M is not one. I'm
sure a wizard could do this, but I'm just a newbie. For
now, I can easily live with the occasional wasted build time.

(2) I would like my ant script to generate the JNI headers into the
build directory, along with all the other products of the build, and
that is straightforward to do. (I pass the path to the Parliament.jar
file as a parameter to the ant script, and it can figure the rest out
from there.) However, if I do this, then the lib target can't find
the JNI headers while building its sources. What I would like to do
is add a usage requirement of "<include>$(<:D)" to the jar file rule,
but $(<) does not appear to have the same meaning at that point in the
jam file as it has inside the jar file's action. Is there a way for
the jar file's rule to add the build directory to the lib target's
<include> feature?

(3) The normal glob-tree rule will only recurse within the project
directory, but my java sources don't live there. After some
spelunking through the sources, I discovered path.glob-
tree, which takes an extra argument for the directory in which the
recursive search is rooted. Is it kosher to use path.glob-tree? If
not, I would suggest that the normal glob-tree should take a third
argument as well -- it's overly restrictive to assume that all
recursive file searches will be rooted in the project directory.

Again, thanks everyone for your help on this little adventure of mine.



import make ;
import path ;

project /KB/KbCore ;

path-constant JavaSrcDir : ../java ;

lib Parliament
        : [ glob *.cpp : Utf8StaticInitGen.cpp ]
        : <include>.
        : # default build
        : <include>. ;

explicit Parliament.jar ;
make Parliament.jar : [ path.glob-tree $(JavaSrcDir) : *.java ] :
@BuildJar ;
actions BuildJar
        ant -DtargetJarPath=$(<)

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at