Subject: Re: [Boost-build] dynamically editing the bjam dependency graph
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-09-02 01:58:32
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
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