From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 06:43:36
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> > I wrote that a long time ago -- I guess I changed my mind about the
> > level feature since I wrote it. In fact, I think I've changed my mind
> > what the meaning of "free" should be.
> And what's the new meaning, in your opinion. I can't gather that from
> previous posts.
Merely that its values can be arbitrary strings, instead of being known to
the system via the feature's declaration or feature.extend.
> > > 2) You say propagated feature apply to top-level targets. Do you mean
> > that
> > > bjam warnings=full
> > >
> > > will cause only top-level targets compiled with full warnings, while
> > > 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?
> Sure, so this part of comment should be updated also.
Okay. When we decide the meanings for all of these feature attributes, I'll
make a pass through and update the comments and code.
> > > > > 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)
> > > 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
> > is
> > > troublesome.
> > 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
> > a *lot* smarter.
> True... but requirements are meant to be rather static, while build
> is not.
> > > Second, after cleaning, he can change requirements for the top-level
> > project
> > > -- they'll apply to *all* targets.
> > Not sure what you mean here... but let me just say that I have no
> > 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
> > be configured with preprocessor macros it should be possible to request
> > configuration on the build command-line. I also think it should be
> > to use, e.g., <cxxflags> as a way of saying "just try the build with
> > compiler options".
> I think you agree that you can accomplish that goal with requirements on
> top-level project.
I'm not sure I agree with that. AFAIK you have to edit a Jamfile to change
Furthermore, if I have a project with 5 libraries and an executable, and I
want to try building libA with -DFOOBAR=BAZ and link it into the rest of
the project as usual, it seems very difficult or impossible to achieve that
by working with top-level project requirements.
> Possibly, we can allow to specify additional top-level
> requirements in the command line? That way, they'll be consistently
> to all targets. I realize that this is rather confusing,
VERY confusing. And I don't see how it provides any of the protection you
say you want, since it's still a command-line interface to essentially the
> but other alternatives are even more confusing for me.
I think we need to keep searching.
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