Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-07 22:49:55
On Aug 7, 2017 1:25 PM, "Steven Watanabe via Boost-build" <
> On 08/05/2017 08:43 PM, Stefan Seefeld via Boost-build wrote:
> > Who or what calls rules ?
> Any jam code can call a rule. Just like any
> python code can call a python function.
Ah, so b2's notion of "rule" has nothing to do with that of make (which is
a means to express how to update targets).
(You mentioned something about reinventing terminology...I prefer new terms
for existing concepts over existing terms changing their meaning. ;-)
> The definition of <use> in Boost.Build, is that
> it takes the usage-requirements, but does not
> create an actual dependency. It should be possible
> to make something similar work, however.
I think that would be very useful indeed.
> Merging from the other sub-thread:
> >> Also, I don't know
> >> how you handle #include scanning, but the way Jam
> >> handles scanners causes cyclic #includes to create
> >> a cyclic dependency in the internal nodes, which
> >> is a total nightmare in the face of a dependency
> >> graph that changes dynamically.
> > I haven't encountered any issues yet. The include-scanning-step is its
> > own intermediate step that injects additional dependencies into the
> > graph, and as long as they lead to existing files (which themselves
> > don't need to be updated), I don't see issues. Where would that create
> > problems ?
> Boost.Build can handle headers that are updated.
> I glanced through your source, and I couldn't see
> where you're handling the include-scanner. Anyway,
> Jam has a somewhat unusual #include scanner, in that
> it scans each header separately, instead of scanning
> per translation unit.
I haven't pushed that codde to github yet. For now I'm using a compiler
action (mapping to "-M" for gcc) to make sure I se exactly the right set of
includes depending on the current CPPFLAGS.
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