From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 06:06:30
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
Sent: Friday, July 12, 2002 6:44 AM
Subject: Re: [jamboost] Disallow free property in build request
> David Abrahams wrote:
> > > But... in our discussion we've agreed that neither free properties in
> > target
> > > requirements nor free properties in build request can be propagated.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > I thought that was in question. As I understood it, you're asking
> > it's OK to prohibit non-propagated free properties from the build
> > 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
> > (i.e. how it works in v1).
> I'm try to be even more specific:
> you have
> exe a : a.cpp libs/library1 : <define>FOO ;
> This project does not require explicit build of "libs" project, i.e.
> reference to libs/library1 is the only reason that library is build.
> You have build request
> Do you think that
> 1) a should be build with <define>FOO and <define>BAR
> 2) libs/library1 should be build without any defines
Well, we can't see the defintion of libs/library1 here, but if there are no
<define> properties in its requirements, then yes, that's what I think.
> BTW, this is exactly what V1 does. See the attached example.
Yes, I know that. It's no accident: I designed it that way.
> I strongly belive that 2) should be true: that neither of defines should
> apply to libs/library1.
Good; we agree.
> Suppose that library1 is used by two different main
> targets with different defines. We'd end up with sources of library1
> with different set of defines.
> Regarding 1): I'm afraid that current V2 behaviour is exactly the same.
> what if project where "a" is defined has "build-project libs ; " Do you
> 1) library1 should be compiled without defines
> 2) library1 should be compiled with <define>BAR
> 3) library1 should be compiled two times, with different settings of
I think #2 is probably the right choice
> No! What do you mean by "propagated"? I thought "propagated" in this
> > context meant that requirements of dependencies are automatically
> > on their dependents.
> I think it is property which applies from target to other main-target
> uses. (that is, I think from a target to its dependencies).
> main a : a.cpp libs/library1 ;
> Here, the propagation is from "a" to "libs/library1" ;
OK, I understand you.
[Wasn't there another kind of propagation you proposed, where, e.g., the
use of a library might automatically add #include paths to the target using
> BTW, can you comment on comment for "propagated" features in
> 1) It implied that propagates features are most often free, yet you say
> warning level should not be free feature.
I wrote that a long time ago -- I guess I changed my mind about the warning
level feature since I wrote it. In fact, I think I've changed my mind about
what the meaning of "free" should be.
> 2) You say propagated feature apply to top-level targets. Do you mean
> bjam warnings=full
> will cause only top-level targets compiled with full warnings, while main
> targets they depend on will use standard warning option?!
Uh, no -- that would sort of defeat any meaning to the "propagated"
attribute, wouldn't it?
> > > I now really feel that free properties in command line is a bad
> > 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
> > with -DFOOBAR=BAZ".
> First, suppose your developer does that from an already (partially) build
> tree. To really try if with -DFOOBAR=BAZ, it would have to run
> bjam clean
> first. It is yet another indication that free properties in command line
Yes, I'm aware of the dangers.
However, those dangers exist for edits to the Jamfiles as well, with
features that don't generate subvariants... unless we make the build system
a *lot* smarter.
> Second, after cleaning, he can change requirements for the top-level
> -- they'll apply to *all* targets.
Not sure what you mean here... but let me just say that I have no problem
with making things safer, as long as there's a reasonably-easy way to
override things to get the special build you want. I don't think this
should always require editing Jamfiles. In particular, when a project can
be configured with preprocessor macros it should be possible to request a
configuration on the build command-line. I also think it should be possible
to use, e.g., <cxxflags> as a way of saying "just try the build with these
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