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

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

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

> >No, they're really different features. Thomas' feature could, for
example,
> >be used to specify the build requirements for Boost.Python modules, but
one
> >should still be able to build any module in any of the variants
> >(debug/release/etc.)
>
> 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

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

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

-Dave