Re: [Boost-build] [generators] add include path to the output folder

From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-08-19 04:56:28

Sven Van Echelpoel wrote:

> Hi,
> 
> I'm creating a generator for ANTLR using Boost.Build v2. By following
> one of the samples I got everything to work, i.e. Boost.Build picks ups
> any .g (grammar) file in the sources and generates the appropriate .cpp
> and .h files. All I need right now is a way for adding the path to the
> output directory to the requirements of target that has this .g file as
> a source. How can I add an <include> feature from within the generator
> rule? 

Do you actually need to? Usually, Boost.Build will automatically add include
paths for targets of type H that are produced inside the same main target.
Is this not happening?

> Most of what I learned about Boost.Build I got from pouring over 
> the code, but this one seems to elude me. Any help would be much
> appreciated.
> 
> This is the generator rule I have so far:
> 
> rule antlr-compile-grammar
> {
>   local ANTLR_HOME = [ modules.peek : ANTLR_HOME ] ;
>   local JARS = [ path.glob $(ANTLR_HOME)/lib : *.jar ] ;
>   
>   if [ os.name ] = NT
>   {
>       ANTLRCLASSPATH = [ string.join $(JARS) : ";" ] ;
>       MV = ren ;
>   }
>   else
>   {
>       ANTLRCLASSPATH = [ string.join $(JARS) : ":" ] ;
>       MV = mv ;
>   }
> }
> actions antlr-compile-grammar
> {
>   "java" -classpath $(ANTLRCLASSPATH) org.antlr.Tool -fo $(<:D) $(>)
>   "$(MV)" $(<:D)/$(<:B).c $(<)
> }

I presume you declare your generator by just

  generators.register-standard ....

? If so, as the first step you need to create a custom generator class. A dummy class
is given as example in http://www.boost.org/boost-build2/doc/html/bbv2/extending/tools.html

Then, you can override the 'run' method and do something like this:

        local base = [ generator.run $(project) $(name) : $(property-set) : $(sources) ] ;
        local requirements = [ property-set.create .... ] ;
        return $(requirements) $(base[2-]) ;

The explanation is that the first element returned by 'run' may be a property-set, in which
case we'll try to add those requirements to other targets. However, this approach may not
always work, for example if you have:

    exe a : a.cpp whatever.g ;

then the top-level generator is gcc.link, which when uses gcc.compile for both a.cpp
and whatever.g (which is converted to cpp). So, whatever extra properties you add will
be passed to gcc.link, but won't be passed, in general, to gcc.compile that compiles a.cpp.
The built-in magic to handle this case is a bit more smarter, so we need to figure if it
does not work, first :-)

- Volodya