Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-08-05 21:14:55

AMDG

On 08/04/2017 10:09 AM, Stefan Seefeld via Boost-build wrote:
> 
> I have outlined the workflow of such a build with three different
> snapshots of the dependency graph:
> * one as it is encoded in the fabscript,
> * one has faber would see it once it has completed parsing the fabscript
> (and any other input, including command-line options), and
> * one some time later, once the dependency graph related to the "C"
> artefact has been expanded by the assembly.
> 
> This corresponds to my own (mental) model, as well as how it is
> implemented in faber (some of which is still work in progress).
> So now I would like to understand whether you see any design flaws (or
> bugs) in this approach, and how that maps to b2's model.
> 

I think that trying to represent both C and C.exe in
the same hierarchy is a bit tricky.
- Anything that depends on C should ultimately see C.exe.
- Similarly, this
  alias sources : 1.cpp 2.cpp 3.cpp ;
  exe C : sources ;
  is a bit harder to deal with if you have an
  intermediate `sources` that exists along side 1.cpp etc.
  In Boost.Build, sources is a main target, but it
  completely disappears at the virtual-target layer.
(This is definitely solvable.  It just makes things
a bit more complicated.)

> In particular, I don't see any fundamental problems in letting almost
> arbitrary features (or "usage requirements") be added in the process. Of
> course, if incompatible values are combined, an error needs to be raised.
> 

This is somewhat different from usage-requirements in Boost.Build.
In your example:
  config = try_compile(source, if_=define('HAS_FEATURE'))
  C = binary('C', 'C.cc', features=config.use)
what we want is to apply this define when building C.exe.
We don't intend it to be applied to dependents of C.
In addition, I don't know if you have something akin to
propagated features, but if you do, then config checks
that set such features *must* be evaluated before building
dependencies and *may* force config checks to be evaluated
multiple times with different feature sets.  This makes
them very different from normal dependencies.

> (Note that I found a simple way to run the config checks without
> requiring synchronization: the outcome of an action is fed back into the
> associated artefact, from which it is available when the next action is
> performed. So the only call to "update_now" is the global one performed
> to update the goals from the command line...)
> 

  I think this is a good idea, but you'll need
to consider very carefully what artifacts should
be updated when a file is touched.

> PS: There are a few terminology changes: I use "artefact" where b2 uses
> "target", and "assembly" where b2 uses "generators". Furthermore,
> "feature sets" replace "property sets". I hope that doesn't distract
> from the overall similarity of the models.
> 

  Why does everyone feel the need to invent their own
terminology?  (I'm not that happy about "features" and
"properties" either for what it's worth.)  The term
"target," at least, is used by good ol' make.

In Christ,
Steven Watanabe