Boost logo

Boost-Build :

From: Jürgen Hunold (hunold_at_[hidden])
Date: 2004-12-01 03:26:54

Hi !

I've got some questions and remarks about the way use-project and
<use>/project work now. I've attached a simple test-case to illustrate
my problems with the current behaviour.

The docs state:
Causes the target referenced by the value of this feature to be
constructed and adds it's usage requirements to build properties. The
constructed targets are not used in any other way. The primary use case
is when you use some library and want it's usage requirements (such as
include paths) to be applied, but don't want to link to the library.

My problem is that the construction of the "target referenced" invokes
"build-project" rules from that target.
Let us take Boost itself as an example.
In my project-a I state

use-project /boost : path-to-boost ;

The current Boost Jamfile.v2 contains several build-project rules which
bjam happily follows and add _their_ usage-requirements, too.
(for concrete output see setup/procjec-b/actions.txt)
For compile-actions I get:


for Boost.Time and Boost.Signals.

When I activate Boost.Python (just change the checks in the current
version to test for 2.3 ;-)) ) I get the Python library-paths in the
link line so V2 happily tries to link _everything_ against

I don't think that this behaviour is good, but can't come up with a
better solution. Simply _not_ following "build-project" in this case
may prevent even header-only boost libraries from compiling (see
-DDATE_TIME_INLINE ), but I don't know much about Boost.Time.

For "real" libraries I think it would be best to let the user explicitly
specify "use /boost/thread" or "use /boost/signals" instead of simply
setting them up in the Background. But I'm not sure about that.
And Boost.Python V2 is not yet finished, so I don't dare to comment on
that ;-))

My "real" problem (yes, now it comes) is the example setup, already
shown in previous mails.
I've got some project-a with some 40 libs and 6 full-size apps. I reuse
some of the libs from project-b with some 8 additional apps.
So I simply say "use-project /project-a : path" and require
"use /project-a".

Unfortunately, this results in _all_ Jamfiles of project-a being
examined because they are _all_ referenced for the apps in project-a.
And this is _slow_. _Very_ slow.
Not in the test-case because it simply has no "real" input and not
enough libs. But for my project it really hurts.

There are two possible solutions:
a) don't follow build-project when "use"ing a Jamfile.
b) make V2 faster. _Much_ faster



* 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] !
 --Boundary-00=_PBYrB6fud0Ra9bo Content-Type: application/x-tbz;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
[Attachment content not displayed.] --Boundary-00=_PBYrB6fud0Ra9bo-- 

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at