Boost logo

Boost-Build :

From: Jürgen Hunold (hunold+lists.Boost_at_[hidden])
Date: 2003-03-05 02:31:34


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Vladimir,

On Tuesday 04 March 2003 09:55, Vladimir Prus wrote:
> Hi Jürgen,
>

> You are correct with your analysis. Here, "a" object is created
> without optimization. Since all main targets inherit
> <dependency>@/boost, this one builds boost, and since
> <optimization>is propagated, builds it with <optimization>off.
>
> Oh, V1 was so simple... no usage requirements, not multiple
> projects.. ;-)
>
> Anyway, I can see three things that contribute the the problem:
> 1. Global <dependency> requirement. Not so bad idea.
> 2. The fact that <dependency> feature cause the build of everything
> in boost. In this case, object file creation does not depend on
> boost, so we need not rebuilding. OTOH, <dependency> features
> explicitly state dependency on something, so we shouldn't be overly
> smart.
> 3. No matter how hard you try, <optimization> is propagated. Now
> I'm not sure this is right. You can request a specific version of
> library
>
> exe a : a.cpp l/<optimization>space ;
>
> but you cannot request specific properties for compiling "a.cpp",
> without affecting "l". I don't like this assymetry.
>
> The best idea, IMO, is to fix 3: introduce 'local requirements',
> which are not propagated. Opinions?

Well, I think something like the second option. I think that bjam
simply fails to distinguish between "compile-against" and
"link-against". The point is that by using <dependency>, I just want
to have the correct <usage-requirement>'s for the compilers command
line. This is "compiling-against" libx, for my example. In my
example, liba does not explicitly link agains libx nor against any
boost library. Still bjam tries to build both libraries "just in
case" the programmer should try to link against them. This _is_
overly smart already, I fear.
I would propose that <dependency>foo just adjusts the compiler options
for object generation according to the <usage-requirements> of "foo",
and then determines whether the programmer actually _wants_ to link
against any lib, object or whatever "foo" provides and then tries to
find or build a version of "foo" using the build-requirement defined
at the point of "real" usage.

The core is that there is no need to build _any_ "external" library
unless the user explicitly wants to use, that means "link against",
it. The best example for this is boost, because the only things I use
are smart_ptr, bind and the BGL. So I don't need boost_signals or the
thread library built, because I don't have to link against them.
This just irritates users, wastes disk space and requires a python
installion until auto-detection of python is working for V2.

Just some thoughts of mine.

One remark: When I cd to liba and issue bjam --v2 clean, bjam cleans
libx, too. I think it even cleans the whole boost tree, too.
This is at least "surprising" behaviour.

Yours,

Jürgen

- --
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen,
Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+ZafWljbJ/LLrxrYRAv8AAJoDjLiEDvJaJvlExidtMIFxqI0DjwCgwpt/
CU9FSR8lcHNoF4jgmuPVlyo=
=CJ1K
-----END PGP SIGNATURE-----

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk