Re: [jamboost] Disallow free property in build request

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
warning
> > level feature since I wrote it. In fact, I think I've changed my mind
about
> > what the meaning of "free" should be.
>
> And what's the new meaning, in your opinion. I can't gather that from
your
> 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
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?
>
> 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)
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
> >
> > 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
system
> > a *lot* smarter.
>
> True... but requirements are meant to be rather static, while build
request
> 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
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
> > compiler options".
>
> I think you agree that you can accomplish that goal with requirements on
the
> top-level project.

I'm not sure I agree with that. AFAIK you have to edit a Jamfile to change
those.
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
applied
> 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
same functionality.

> but other alternatives are even more confusing for me.

I think we need to keep searching.

-Dave