From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 12:02:44
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> I think this is the root of our disagreement. I was objecting to free
> properties in command line because they would apply only to the top-level
> targets. You, on the other hand, intentionally implemented that behaviour
> I now start to understand your motivation. You mean that free properties
> applied only to the project you build, not to any targets that are used
> elsewhere. I.e. I want to rebuild "lib1" with some define, and don't want
> targets from "lib2" to be build with that define only because there're
> from "lib1"?
> I now think that motivation is reasonable. (And that decision
> allows to leave existing code almost intact). However, I'd much
> you could put express your motivation in good English so that we can
> it in docs.
We have to decide the meanings of various feature attributes first. Remind
me once that's done.
> So, let's agree that
> 1) Free properties are allowed in build request
Not sure what free means right now, but OK. All properties are allowed in
> 2) They apply only to top-level targets, i.e. targets in the current
> and those for which build-project was called.
> 3) If a target is both top-level target, and used by other top-level
> it is build with the properties as-if it were simply top-level target.
> Is this proposal ok?
Fine. Can we call these top-level targets "directly requested" instead? I
think it's much more memnonic than "top-level".
> > Did you miss the post where I wrote:
> I did not have in cache when writing the last message, sorry.
> So what do we have about properties now.
> I suggest these axes:
My intention was that every feature attribute was an orthogonal axis.
> 1. principal -> minor -> trait
This sounds like a high-level classification of feature attribute sets into
named groups... is it neccessary/useful?
> Principal features are for most important things like variant,
> or threading. They are propagated and generate subvariant dir.
> Minor features are for fine-tuning build. Defines fall there. They don't
> generate subvariant build but are handled like free features are now: if
> set of minor features for some target is not equal to project
> that target location is augmented with its main target name.
> Minor features are not propagated (like free features now)
> Trait features have no effects on build process at all. They are for
> control etc. I think we can safely have them always propagated.
Sounds OK, though I don't like the name "trait". I'd rather call them
"incidental" or something which indicates their lack of impact.
> 2. single-valued -> multi-valued
> The first kind can have only one value per target and that value can be
> finite set. The second kind can have several values per target and they
> (I see not use for features with several possible values per target with
> values from finite set. And the same about features with arbitrary values
> which can be set only once per targets).
> 3. optional and symmetric are just two flags which apply only to single
> values features.
Why? Wouldn't it be simpler just to leave every feature attribute as an
orthogonal axis to all others?
> The proposal above is just a slightly refined version of the current (V1)
> semantics, so it's easy to do what you want.
I'm not sure that I see the value of grouping the attributes in this way.
One of the problems I had in v1 was that I kept discovering features which
needed to work "mostly like" some category of feature, "except for..."
Part of my motivation for separating all the attributes as I have done in
v2 was to avoid having prescribed combinations prevent us from doing what
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