Boost logo

Boost-Build :

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


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk