From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-12 05:44:24
David Abrahams wrote:
> > 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).
I'm try to be even more specific:
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
BTW, this is exactly what V1 does. See the attached example.
I strongly belive that 2) should be true: that neither of defines should
apply to libs/library1. Suppose that library1 is used by two different main
targets with different defines. We'd end up with sources of library1 compiled
with different set of defines.
Regarding 1): I'm afraid that current V2 behaviour is exactly the same. But:
what if project where "a" is defined has "build-project libs ; " Do you think
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 debug.
> > > 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 think it is property which applies from target to other main-target that it
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" ;
BTW, can you comment on comment for "propagated" features in features.jam.
1) It implied that propagates features are most often free, yet you say
warning level should not be free feature.
2) You say propagated feature apply to top-level targets. Do you mean that
will cause only top-level targets compiled with full warnings, while main
targets they depend on will use standard warning option?!
> > 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
> 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
first. It is yet another indication that free properties in command line is
Second, after cleaning, he can change requirements for the top-level project
-- they'll apply to *all* targets.
I've skipped the remainder of your email. Let's agree on the part above
before changing feature kinds.
- Volodya --------------Boundary-00=_0UT4CNRURV79EK8IKUHE Content-Type: application/x-zip;
Content-Disposition: attachment; filename="P.zip"
[Attachment content not displayed.] --------------Boundary-00=_0UT4CNRURV79EK8IKUHE--
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