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 01:58:32

AMDG

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:
>> 
>>> Does this approach sound reasonable ? Am I overlooking some cases ?
>>>
>> - What happens if the dependencies are added after a
>>   target has completed updating?
> 
> It should raise an error.
> 
>> - Can it hang when the added dependencies create a cycle?
> 
> Can the cycle be detected ? (There seems to be some code in the engine
> to do that.)
> 

  cycles are detected when we see a back edge in the DFS in make0.
Since you're adding the dependencies later I don't think they'll
be noticed without extra work.

>> - 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.

>> - 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.

In Christ,
Steven Watanabe