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

From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2008-08-26 07:44:51

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? 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.

3. The implicit dependency feature, as suggested again by VP, does not
work for me, presumably because #1 doesn't work either.
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.
Thanks,
Sven