On Aug 7, 2017 1:25 PM, "Steven Watanabe via Boost-build" <boost-build@lists.boost.org> wrote:
> 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.

Stefan