Re: [jamboost] patch boost-base.jam project wide settings

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-02-26 12:22:13

On 2002-02-26 at 11:45 AM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>
>----- Original Message -----
>From: "Rene Rivera" <grafik666_at_[hidden]>
>
>
>> I just don't see that they are different features. To me it looks like a
>> different desing
>
>? I don't know that word, nor does
>http://www.merriam-webster.com/cgi-bin/dictionary

Oops, I do that way to often :-]

>> and implementation of the same feature. And is possibly a
>> better way of solving the problem, given that it doesn't tie it to the
>> variants.
>
>It solves a different problem. Build variants are supposed to be orthogonal
>to target requirements.
>
>> I don't see how you can't use the "variant" to specify requirements for
>> Boost.Python modules. The important rules take the local-build argument,
>and
>> they call declare-local-target. Did I miss something when looking at the
>> python.jam code?
>
>I don't know, but notice that there's a $(PYTHON_PROPERTIES) variable which
>is used to transmit standard settings for extension modules. Note also how
>it's (ab)used in libs/python/Jamfile.

Aahh, yes I see how it would solve that problem!

>> But, to me using the variant matches more closely to what MSVC,
>CodeWarrior,
>> and other IDEs do (although CW doesn't have inherited settings).
>
>That's because all of those IDEs fail to distinguish target requirements
>from the abstract build variant. Target requirements should include
>properties which are /essential/ to the target (e.g. multithreading,
>#include paths, libraries, etc.), while a build variant should be a simple
>way of naming a bunch of requested optional BUILD properties (debug symbols,
>inlining, optimization, profiling,...). If requested build properties are
>incompatible with the target requirements, the target should not be built.

Point taken, and I agree. I can see how Thomas' way of doing this is better.

[Take the following as: I'm willing to help get this feature into the code.]

Would it then make more sense to reformulate the syntax so that it better fits
the duality if the variant vs. requirement-set. What I'm thinking of is
reformulating the syntax so that is looks more like variant. For example the
following instead of Thomas' example:

requirements TplBase
:
<include>../myinclude
<define>TEMPLATE
;

requirements TplDerived : TplBase
:
<include>../anotherinclude
<define>DERIVED_TEMPLATE
;

exe MyExe
:
main.cpp
:
<requirements>TplDerived
:
debug
;

This way it would make adding the build settings extension easier. And makes
the variant, requirements, and "settings"? all orthogonal.

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