Boost logo

Boost-Build :

Subject: Re: [Boost-build] how to use exe target from generator tool
From: George Georgiev (george.georgiev.sf_at_[hidden])
Date: 2012-03-17 17:26:03


Thank you Steven,

It looks like it does not work as described. This is my scenario:

-------- a.compil ----------

# metadata for a

-------- b.compil -----------

import "a.compil" ;

# metadata for b that depends on the meta data of a

------- jamfile ------------

lib compil-test :

Note that I even do not have cpp files in this library. Now when the
compil compiler generate the h and cpp files they will looks like:

----------- a.h --------------

// c++ header of a

----------- a.cpp -----------

#include "a.h"

// c++ implementation for a

---------- b.h --------------

#include "a.h"

// c++ header of b

----------- b.cpp -----------

#include "b.h"

// c++ implementation for b

There are two issues that I am experiencing (so far):

1. In the very beginning (clean build) the order of executing generate
a.compil and compile b.cpp is not guaranteed. Which results in attempt
b.cpp to be compiled even before a.h on which it depends to be

2. In incremental scenario when a.compil is modified b.cpp is not
recompiled. I believe this is happening, because at the time of
scanning the dependencies of b.cpp - a.h - is still older.

With other words it looks like the implicit dependency for the targets
in the same library/executable propagate only for first level targets,
but not for targets result of another generation process.

Is this make sense?

If I do:

------- jamfile ------------

lib compil-test-level1 :

lib compil-test :

This works, but I will prefer if I do not need to maintain these
dependencies anywhere else but the files themselves.

Is somebody knows some generator that already have this solved, please
point me to it. For example if somebody have google protocol buffers
already integrated they will have the same issues.


On Wed, Feb 29, 2012 at 1:50 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> On 02/29/2012 01:32 PM, George Georgiev wrote:
>> Thank you Steven,
>> This will help only after the rules define these dependencies though.
>> Do you know where I can find an example how .y generator is defined.
> <implicit-dependency> doesn't have to be precise.
> It only indicates a /potential/ dependency for
> the include scanner to resolve.  Thus, you can do
> something like:
> exe tool : file1.cpp file2.cpp file3.compil file4.compil ;
> All the #includes will be resolved automatically.
> If you have separate targets, then you need
> something like:
> cpp file3.cpp : file3.compil ;
> cpp file4.cpp : file4.compil ;
> alias headers : file3.cpp file4.cpp ;
> for local i in 1 2 3 4 {
>  obj file$(i).o : file$(i).cpp : <implicit-dependency>headers ;
> }
> In Christ,
> Steven Watanabe
> _______________________________________________
> Unsubscribe & other changes:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at