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

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