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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-26 12:38:11

Very nice; please go for it. You and Thomas can work out the details.

Best,
Dave

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Tuesday, February 26, 2002 12:22 PM
Subject: Re: [jamboost] patch boost-base.jam project wide settings

> 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]
>
>
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>