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

Subject: Re: [Boost-build] dynamically editing the bjam dependency graph
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-09-02 03:27:44

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.

>>>> - Is it correct for dependencies added in between two calls
>>>>   to UPDATE_NOW?
>>> Why not ? In fact, I don't expect multiple calls to UPDATE_NOW. There is
>>> no API that exposes that to users. With my current design there simply
>>> is no need for it. config checks etc. are all simply artefacts like any
>>> others that are declared and executed as per the (dynamic) dependency graph.
>>>
>>   The potential issue is that you shouldn't push
>> states onto the make1 stack when make1 is not
>> currently executing.
> 
> Right. Well, I thought I have handled that by looking at the target's
> fate (to see whether the target is being updated right now), and only
> pushing the new dependencies onto the stack if it is. Is this not enough ?
> 

Maybe?  As long as you've considered it, I'm not going
to worry about it too much.

In Christ,
Steven Watanabe