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-18 15:46:24


Hi,

I finally found what the problem is. I had my generator marked to
generate only CPP files. Now when I added that it generates H files
too everything works as expected.

Thanks,
George

On Sat, Mar 17, 2012 at 2:26 PM, George Georgiev
<george.georgiev.sf_at_[hidden]> wrote:
> Hi,
>
> 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 :
>    a.compil
>    b.compil
>    ;
>
> 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
> generated.
>
> 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 :
>    a.compil
>    ;
>
> lib compil-test :
>    b.compil
>    :
>    <implicit-dependency>compil-test-level1
>    ;
>
> 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.
>
> Thanks,
> George
>
>
>
>
>
>
> On Wed, Feb 29, 2012 at 1:50 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>> AMDG
>>
>> 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: http://lists.boost.org/mailman/listinfo.cgi/boost-build


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk