Re: [Boost-build] Problem with notfile target

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 boost.build 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 boost.build 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.

-Ian

=========================

import make ;
import path ;

project /KB/KbCore ;

path-constant JavaSrcDir : ../java ;

lib Parliament
        :	[ glob *.cpp : Utf8StaticInitGen.cpp ]
                /site-config//BerkeleyDB
                /site-config//JavaJNI
        :	<include>.
                <define>BUILDING_KBCORE
                <define>PARLIAMENT_RSRC_AS_UTF16
                <define>_REENTRANT
                <threading>multi
                <dependency>Parliament.jar
        :	# default build
        :	<include>. ;

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