Boost logo

Boost-Build :

Subject: Re: [Boost-build] [generators] Adding usage requirements to generated target
From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2008-09-16 04:36:03


Hi,

I'm sorry I didn't respond any earlier, but I was out for two whole
weeks and didn't come near my email in that time. Right now I have some
more urgent matters to attend to first. As soon as I can I will look
into your suggestions and report back.

Thanks for the help so far,

Sven

On Mon, 2008-09-01 at 12:46 +0400, Vladimir Prus wrote:
> On Tuesday 26 August 2008 15:44:51 Sven Van Echelpoel wrote:
> > Hi,
> >
> > I feel I must come back to my question of a couple of days ago (See
> > http://www.nabble.com/-generators--add-include-path-to-the-output-folder-tt19046275.html). While the response has been very helpful so far, I'm still left with a couple of questions and I feel the thread died a little too prematurely :-) Apologies if someone responded to my last questions and I failed to see that.
> >
> > To recap: I created a generator (following the soap example) for
> > compiling ANTLR grammars. Such a compilation generates 2 C++ source
> > files and 2 headers. The source files are compiled into a static library
> > and that library is used by another executable. I would like to add the
> > path to the generated headers to the usage requirements of that library
> > automatically.
> >
> > Some observations so far:
> >
> > 1. The include path to the headers is *not* automatically added to the
> > main target that has a particular ANTLR grammar file as source. Vladimir
> > Prus suggested that BB normally automatically adds this.
> > 2. Originally my generator did not create targets for the generated
> > header files. Is this required?
>
> Yes. If you don't tell the truth about what targets your tool produces,
> then some things will be broken -- auto-add of includes is one of them.
>
> > Here's my latest generator's run rule:
> >
> > rule run ( project name ? : property-set : sources * )
> > {
> > if ! $(sources[2])
> > {
> > # Accept only single source.
> > local t = [ $(sources[1]).type ] ;
> > if $(t) = ANTLR_GRAMMAR
> > {
> > # The type is correct.
> >
> > # If no output name is specified, guess it from sources.
> > if ! $(name)
> > {
> > name = [ generator.determine-output-name $(sources) ] ;
> > }
> >
> > local compile_grammar = [ new action $(sources[1]) :
> > antlr.antlr-compile-grammar : $(property-set) ] ;
> > local compile_grammar_target = [ new file-target
> > $(name)Parser :
> > CPP : $(project) : $(compile_grammar) ] ;
> >
> > local grammar_header_target = [ new file-target $(name)Parser :
> > H : $(project) ] ;
> >
> > local create_lexer = [ new action $(sources[1]) :
> > antlr.antlr-compile-lexer : $(property-set) ] ;
> > local create_lexer_target = [ new file-target $(name)Lexer :
> > CPP : $(project) : $(create_lexer) ] ;
> > local lexer_header_target = [ new file-target $(name)Lexer :
> > H : $(project) ] ;
> >
> > return [ virtual-target.register $(compile_grammar_target) ]
> > [ virtual-target.register $(create_lexer_target) ]
> > [ virtual-target.register $(grammar_header_target) ]
> > [ virtual-target.register $(lexer_header_target) ] ;
> >
> > }
> > }
> > }
> >
> > I added targets for the H files without actions (because they are
> > already produced by the first action compile_grammar_target (the CPP
> > target just renamed a C file into a CPP file). I also tried adding H
> > targets with empty actions ( actions do-nothing { } ), but that did not
> > work either.
>
> You need to indicate that H files are produced by the same action as
> CPP, e.g:
>
> local lexer_header_target = [ new file-target $(name)Lexer :
> H : $(project) : $(create_lexer) ] ;
>
> > 3. The implicit dependency feature, as suggested again by VP, does not
> > work for me, presumably because #1 doesn't work either.
>
> Exactly.
>
> > Here's what I tried:
> >
> > lib antlr-parser : < .. sources .. >
> > : <link>static <warnings>off <include>$(PROJECT-INCLUDES)
> > <include>$(PRIVATE-INCLUDES)
> > :
> > : <include>$(PROJECT-INCLUDES)
> > ;
> >
> > exe auto-include-test : < .. sources .. >
> > : <implicit-dependency>antlr-parser
> > ;
> >
> > Should that work?
> >
> > --
> >
> > In short, I would like the following to work:
> >
> > # my_parser.g is an ANTLR grammar file
> > lib my_parser_lib : my_parser.g
> > ;
> >
> > # tool.cpp includes the headers generated from my_parser.g
> > exe my_tool : tool.cpp my_parser_lib
> > ;
> >
> >
> > I think I want the include path added to the usage requirements of the
> > lib target. Is this possible and if so, how? In his response Vladimir
> > said that the first element returned from a run rule may be a property
> > set. I'm guessing these are requirements, right. Are they translated
> > into usage requirements somehow or in any way propagated to other main
> > targets? If usage requirements are not the way to go, what other
> > alternatives do I have (given that #3 above doesn't work for me,
> > although I may be missing something there too)?
> >
> > Any help would be very much appreciated. So far using and extending BB
> > for our own purposes have been a true delight. It is an astonishing tool
> > and it would be even more breathtaking were it to support this use case
> > as well.
> >
> > Oh yeah, I'm using BB that comes with Boost 1.36 on Linux with gcc 3.4,
> > should that matter.
>
> If adjusting the H targets as I indicate above fails to work, I'd need a
> self-contained minimal project that reproduce this issue, and I'll take
> a look.
>
> - Volodya


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