Re: [Boost-build] [generators] Adding usage requirements to generated target

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-09-01 04:46:30

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