Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-12 08:10:39

David Abrahams wrote:
> ----- Original Message -----
> From: "Vladimir Prus" <ghost_at_[hidden]>
>
> > David Abrahams wrote:
> > > > > > BTW, this is exactly what V1 does. See the attached example.
> > > > >
> > > > > Yes, I know that. It's no accident: I designed it that way.
> > > >
> > > > Sorry, but I don't understand why is it so. If I say
> > > > <cxxflags>-funsigned-char in command line, I'd expect that to apply
>
> to
>
> > > > every compilation.
> >
> > No comment on this?
>
> No. You're allowed to have your expectation. Maybe we should accomodate it.

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"? 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.

So, let's agree that
1) Free properties are allowed in build request
2) They apply only to top-level targets, i.e. targets in the current projects 
and those for which build-project was called.
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?

> > > Merely that its values can be arbitrary strings, instead of being known
>
> to
>
> > > the system via the feature's declaration or feature.extend.
> >
> > Well, that's okay, but we'd need orthogonal principal feature -> minor
> > feature axis as well. Do you mean that free property can be also
>
> multivalued,
>
> > or that's another axis?
>
> 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:

1. principal -> minor -> trait 

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.

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).

3. optional and symmetric are just two flags which apply only to single 
values features.

> Let me give you another use-case, for example. I just added a switch called
> BOOST_PYTHON_TRACE_REGISTRY to Boost.Python, which prints out a bunch of
> diagnostic info for testing purposes. If I want to use it, all I have to do
> is:
>
> bjam "-sBUILD=<define>BOOST_PYTHON_TRACE_REGISTRY" -a registry.obj
>
> It has the advantage of being entirely temporary. I don't have to edit the
> Jamfile, and there's no risk that I'll check in the Jamfile with this
> option mistakenly enabled for everyone.
>
> There *must* be an easy way to do things like this.

The proposal above is just a slightly refined version of the current (V1)
semantics, so it's easy to do what you want.

> > > I think we need to keep searching.
> >
> > Definitely. Personally, I'll get some pizza and hope my brain will be
>
> working
>
> > better in 15 minutes ;-)
>
> How is the pizza in Moscow?

Depends on where you buy it... the one I've just eaten was rather good.

- Volodya