Re: [jamboost] Disallow free property in build request

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
in
> V2.
>
> I now start to understand your motivation. You mean that free properties
are
> applied only to the project you build, not to any targets that are used
from
> 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
used
> from "lib1"?

Right.

> I now think that motivation is reasonable. (And that decision
> allows to leave existing code almost intact). However, I'd much
appreciate if
> you could put express your motivation in good English so that we can
include
> 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
build requests.

> 2) They apply only to top-level targets, i.e. targets in the current
projects
> and those for which build-project was called.

Sure.

> 3) If a target is both top-level target, and used by other top-level
target,
> 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,
optimization
> 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
the
> set of minor features for some target is not equal to project
requirements,
> 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
warning
> 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
from
> finite set. The second kind can have several values per target and they
are
> arbitrary.
>
> (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).

OK.

> 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
we want.

-Dave