Re: [boost] Boost Build improvements [RESEND]

From: Rene Rivera (grafik_at_[hidden])
Date: 2001-12-16 12:25:39

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

>> These two changes make it so that I can, in my project, do something as
>such:
>> >>>
>> project-root ;
>>
>> variant thot-common
>>     :   <threading>multi
>>         <rtti>off
>>         <sysinclude>$(CVSROOT)
>>     ;
>>
>> 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 ;

>
>>
>> variant thot-release on thot-common release : ;
>>
>> variant thot-profile on thot-common profile : ;
>>
>> >>>--a bunch of stuff cut here--
>>
>> subinclude utilities/diff_test ;
>>
>> subproject utilities/diff_test ;
>>
>> exe diff_test
>>     :   diff_test.cpp
>>         ../../base/Difference.cpp
>>         ../../base/DataTransferImp.cpp
>>         <lib>../../opencl
>>     :   <sysinclude>$(OPENCL)
>>     :   thot-debug thot-profile
>>     ;
>> >>>
>> It's simple, easy to read, and makes managing global settings a breaze. It
>> also happens to make for a much smaller "features.jam".
>
>It sounds like a major improvement. Have you been following the jamboost
>discussions (jamboost_at_[hidden])? They've been a little quiet lately,
>but I plan to start them up again in the next couple of days, now that I
>have a head of steam on the Python rewrite. I ask because the way you're
>using this sounds like it's related to Vladimir's idea of being able to deal
>with a project/subproject as a target which can have its own build
>properties. These properties would be inherited by the targets defined in
>the project unless they specify properties of their own.

Wasn't aware there was a jamboost specific list :-\ I'll go read :) 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.

>> The files that I changes are attached, but they are based of the 1.25.x
>> versions so it would take a bit of work from someone, hint-hint, to
>integrate
>> into the latest and greatest.
>
>Thanks, I'll look, but a patch against the current CVS would be a big help.

I'll see if I can manage to create some patches, maybe later today or
tomorrow, I have UNICODE problems to deal with first :-(

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]