From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-11 14:41:46
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> > > have exactly opposite opinions.
> > Not exactly: I was proposing to simply use an existing free feature,
> > <define> to achieve that effect. You were the one who suggested that
> > should be a feature at all. Once we do that, I think it should be a
> > non-free non-propagated non-subvariant link-compatible feature.
> But... in our discussion we've agreed that neither free properties in
> requirements nor free properties in build request can be propagated.
I thought that was in question. As I understood it, you're asking whether
it's OK to prohibit non-propagated free properties from the build request,
and I'm bringing up examples which only work if they're allowed.
> How will <define> setting will take effect?
I don't understand the question. It would take effect in "the usual way"
(i.e. how it works in v1).
> > Still, I can easily imagine a user wanting to "just build this thing
> > with -DFOOBAR=BAZ" (non-propagated). If we take your proposal, it's
> > basically saying that some feature must be specially designed by the
> > Jamfile writer to handle any such configuration.
> So, you're saying that free properties in build request should propagated
> to *all* targets?
No! What do you mean by "propagated"? I thought "propagated" in this
context meant that requirements of dependencies are automatically imposed
on their dependents.
> I don't like this idea, actually. As for user wanting
> "-DFOOBAR=BAZ" in command line: well, allow that and you can't guaranteed
> correct build anymore. User touches some files and rebuild *some* targets
> with different defines. You can't catch that.
No, you can't.
> I now really feel that free properties in command line is a bad thing.
I understand your concern, but I don't want to overly compromise
ease-of-use in the name of safety. A build system has to work for a
developer who knows what he's doing and "just wants to try it
> > > Also, not sure that having only a single value per target can be used
> > > distinguish targets. Will "warning level" be free feature, for
> > I don't think so.
> Because it can have only one value per target?
Yes, and because its values are pre-defined.
> In which case we'd have to
> somehow refine the definition of free property. For me, it's some minor
> aspect of the build process. It affects something but the person running
> build system should be isolated from them. For example, I'd say that
> request specifying include paths is rather strange.
In general, that's right. However, you might want to "just try the build
with this other directory shadowing the standard library headers"
> I think we can just add a kind of free property which can have only one
> value. This is an alternative to non-free features without subvariant
> and I think it's better. Let's keep ordinary features simple: they
> significally affect build and generate subvariant dir.
Then let's just scrap the notion of "free" properties and introduce two
orthogonal attributes as a replacement:
Maybe there is still a place for a "free" attribute which means that the
feature's values can be arbitrary text (like <define> and <include>).
Warning levels would not be free, since we'll want to pick some useful
> > > Hmm.. either you expand that property before calling generate the
> > > project target (and your free <define> properties won't be
> > Which is what I want in this case.
> You want them to be propagated?
No, I want them NOT propagated in this case.
> > I think generator matching and definition is a relatively complicated
> > process. If someone is defining a project which just needs a macro for
> > configuration, I don't want them to have to understand everything about
> > generators in order to support it.
> There's yet another approach. We can convert <python-arity> into define
> passing properties to the actual generating rule (the one which
> jam's build action). So, there will be some special handling of features
> prior to construction. Your idea about assining classes to features can
> used there.
> This is not going to be very heavyweight.
Not sure I understand, but I think that's what I was suggesting.
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