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