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