Re: [jamboost] Disallow free property in build request

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 06:06:30

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <jamboost_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
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:
>
> 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
>
> <define>BAR
>
> 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
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
> that:
> 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.

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
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" ;

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
the library?]

> 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.

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
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?

> > > 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.

> 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".

-Dave