[V2] use-project and use or need for speed

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:
--snip--
use
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. 
--snap--

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:

-DBOOST_DATE_TIME_DYN_LINK=1 
-DBOOST_SIGNALS_NAMESPACE=boost_signals 
-DDATE_TIME_INLINE 

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

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

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