Re: [jamboost] Disallow free property in build request

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

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

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

bjam warnings=full

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

bjam clean 

first. It is yet another indication that free properties in command line is 
troublesome. 

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;
name="P.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="P.zip"

[Attachment content not displayed.] --------------Boundary-00=_0UT4CNRURV79EK8IKUHE--