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 02:37:49

On 09/01/2017 09:58 PM, Steven Watanabe via Boost-build wrote:
> 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.

OK, I'll look into that, then.
>>> - 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 ?
>>> - 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 ?

Thanks,
        Stefan

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