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

From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2008-08-19 05:53:18

Hi,

thanks for the quick response!

On Tue, 2008-08-19 at 12:56 +0400, Vladimir Prus wrote:
> 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?

Err.. yes this is happening, but what I meant to say was, I need to add
it to the usage requirements. The parser and lexer get built into a
static library, which I then want to use to test the parser. Both the
generated parser and lexer compile fine though. I just also need access
to the types declared in the generated header.

> 
> > 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
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build