Re: [Boost-build] [generators] add include path to the output folder

From: Sven Van Echelpoel (sven.van.echelpoel_at_[hidden])
Date: 2008-08-20 03:36:20

On Tue, 2008-08-19 at 14:06 +0400, Vladimir Prus wrote:
> On Tuesday 19 August 2008 13:53:18 Sven Van Echelpoel wrote:
> > Hi,
> > 
> > thanks for the quick response!
> > 
> > On Tue, 2008-08-19 at 12:56 +0400, Vladimir Prus wrote:
> > > Sven Van Echelpoel wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I'm creating a generator for ANTLR using Boost.Build v2. By following
> > > > one of the samples I got everything to work, i.e. Boost.Build picks ups
> > > > any .g (grammar) file in the sources and generates the appropriate .cpp
> > > > and .h files. All I need right now is a way for adding the path to the
> > > > output directory to the requirements of target that has this .g file as
> > > > a source. How can I add an <include> feature from within the generator
> > > > rule? 
> > > 
> > > Do you actually need to? Usually, Boost.Build will automatically add include
> > > paths for targets of type H that are produced inside the same main target.
> > > Is this not happening?
> > 
> > Err.. yes this is happening, but what I meant to say was, I need to add
> > it to the usage requirements. The parser and lexer get built into a
> > static library, which I then want to use to test the parser. Both the
> > generated parser and lexer compile fine though. I just also need access
> > to the types declared in the generated header.

OK, I have to retract this. I forgot that, in order to continue working,
I hard-coded the path to the output directory in my jamfile. When I
remove this, no include path is added in that main target.

Thinking about it some more I realized that maybe I should add a target
for the H file as well, right. I did not do this before, just for the
CPP files that are generated. So I went back and updated by generator to
also add targets for the H files. Unfortunately that did not help
either. Still no includes added :-(

Here's my latest version of the generator's run rule (adapted from the
soap example):

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.

> 
> Ok, so you have:
> 
> 	lib parser : parser.g ;
> 	exe whatever : whatever.cpp parser ;
> 
> ? In that case, you can either use the implicit-dependency feature,
> as documented at:
> 
> 	http://www.boost.org/boost-build2/doc/html/bbv2/reference/generated_headers.html
> 
> or you actually need to make the generator add usage requirements, as I've described
> in the previous post.
> 
> Personally, I always got away with <implicit-dependency>, whether you're willing to
> use just that, or modify the generator, is up to you :-)

It does not work for me yet, presumable because of the above problems.
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?

Thanks again,

Sven