Re: [Boost-build] dynamically editing the bjam dependency graph

Subject: Re: [Boost-build] dynamically editing the bjam dependency graph
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-09-02 12:04:01

On 09/01/2017 11:27 PM, Steven Watanabe via Boost-build wrote:
> AMDG
>
> On 09/01/2017 08:37 PM, Stefan Seefeld via Boost-build wrote:
>> On 09/01/2017 09:58 PM, Steven Watanabe via Boost-build wrote:
>>> On 09/01/2017 07:00 PM, Stefan Seefeld via Boost-build wrote:
>>>> On 09/01/2017 08:49 PM, Steven Watanabe via Boost-build wrote:
>>>>> - How does this interact with cyclic #includes of generated headers?
>>>> I have no idea yet. As I mentioned, I (intend to) handle include parsing
>>>> quite differently from b2, i.e. I scan for include directives and submit
>>>> the found headers as prerequisites via calls to `builtin_depends`. How
>>>> do you expect this to interact ? Do you expect any difficulties ?
>>>>
>>>   As far as fixing up the dependency graph is concerned,
>>> your include parsing is essentially the same as what b2
>>> already does.  The main issue is that the fixing-up needs
>>> to be done in a compatible way.  I needed some extra bookkeeping
>>> to handle this case.  I suppose if you're planning to
>>> drop support for HDRRULE/HDRSCAN and replace it with your
>>> own system, then it doesn't really matter.
>> OK. I still don't quite understand how cycles may occur in this context.
>> Can you give an example ?
> a.h:
> #include "b.h"
>
> b.h:
> #include "a.h"
>
> a.cpp:
> #include "a.h"
>
> The dependency graph looks like:
> a.exe -> a.cpp a.cpp(internal node)
> a.cpp(internal node) -> a.h a.h(internal node)
> a.h(internal node) -> b.h b.h(internal node)
> b.h(internal node) -> a.h a.h(internal node)
>
> Note that INCLUDES are recorded in the internal nodes,
> and a dependency on x implies a dependency on x(internal node).
>
> The cycle is between a.h(internal node) and b.h(internal node).
> This cycle is not considered an error.

why does bjam treat includes differently ? Is that only to be able to
deal with these cycles, or are there other reasons ?
(I haven't thought about how to deal with such cycles yet, but am wary
to use a separate mechanism. I'd rather try hard to keep things simple,
if possible.)

Thanks,
        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...