Re: [jamboost] Disallow free property in build request

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-07-12 06:35:37

David Abrahams wrote:

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

Sorry, but I don't understand why is it so. If I say 
<cxxflags>-funsigned-char in command line, I'd expect that to apply to every 
compilation.

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

This feels "righter" to me than all the others, too. But I find the 
difference with the case where there's not "build-project" rather confusing. 
Can you give a rationale, again.

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

There was. I think we've agreed that there every target will be able to 
declare "exported" requirements. They need not correspondind to special 
feautre attributes.

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

And what's the new meaning, in your opinion. I can't gather that from your 
previous posts.

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

> > > > 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. 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, but other 
alternatives are even more confusing for me. 

- Volodya