Re: [boost] Boost Build improvements [RESEND]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-16 14:01:58

----- Original Message -----
From: "Rene Rivera" <grafik_at_[hidden]>

> On 2001-12-16 at 12:07 PM, david.abrahams_at_[hidden] (David Abrahams)
> wrote:
>
> >
> >This is fantastic. It was a feature I had originally designed into
> >the system, but scrapped because of the following complication:
> >what happens if I define a build variant, say debug-python, derived
> >from another, say debug, and someone hands me a Jamfile which
> >specifies a requirement: <debug><define>FOOBAR. Does FOOBAR get
> >defined when we build the debug-python variant?
> >
> >How does your patch approach the problem?
>
> I believe, don't hold me to this as I haven't tested it :-), it
> would not. The reason is because the features on the variants, even
> the child variants, get defined with the specific variant not with
> the targets.

I can't envision what it would mean to define features "with a target".

> Unless you do something recursive like: variant one on
> one. would you get that problem, and others I'm sure ;-)

I think I don't understand either of those sentences.

> >> variant thot-debug on thot-common debug : ;
> >---------------------^^
> >
> >That's really cute, but I have a reservation: "on" is a
> >keyword. Jam is kind of funny about letting you use keywords as
> >regular symbols in other contexts, but it makes me nervous. What
> >about this instead:
> >
> >    variant thot-debug : thot-common debug ;
> >
> >Now, what does it mean? ;-)
> >
> >I can guess that it means that thot-debug is everything in
> >thot-common plus every additional property given by the debug
> >variant.
>
> I know, I'm a bit nervous about it also, but the "on" is totally
> superfluous and is only there to make it easier to read :-) I did
> think about doing the way you suggested, but I could figure out how
> to be backward compatible that way... how would I tell the
> difference between:
>
>     variant two : one ;
>
> and
>
>     variant three : <threading>multi ;

You can check whether there's any grist on the first element of the 2nd
argument with:

if $(>[1]:G) ...

>
> Wasn't aware there was a jamboost specific list :-\ I'll go read :)

Also check out the Wiki at:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build
The information there is pretty disorganized (sort of like the current build
system code), but I'm trying to write a document that brings it all
together.

> And yes it does sound like it's similar. And my original drive was
> that I have a good number of targets in various subprojects. It
> might also be related to another problem I have of trying to defined
> static library targets but not really wanting them to be built by
> themselves, only when they are required by a target.

you can use this undocumented trick:

{
    local gSUPPRESS_FAKE_TARGETS = true ;
    lib my-lib : source1.cpp... ;
}

and of course you can wrap that trick into a new rule for defining your
static libs.

-Dave