Boost logo

Boost-Build :

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

Hash: SHA1

Hi Vladimir,

On Wednesday 05 March 2003 09:00, Vladimir Prus wrote:
> Hi Jürgen,

> OK, let's restrict discussion for your example: liba which uses
> libx. One possibility you talk about is just grab
> usage-requirements from libx. Another is to really build libx. To
> tell the truth, I too don't like the idea of building entire boost
> just to get single include ;-)

That's good ;-)

> > 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.
> I think determining what the programmer _wants_ is really quite
> simple: all libraries it wants are in sources or <library>
> properties. Note that today, there only two "dependency" features:
> <dependency> and <library>. The first is mostly used to get at
> usage-requirements. The second is used to *build* the specified
> library and link it to the application. Unfortunately, the first
> one builds everything as well (but throws the results away).

Oh, I should have written that I figured this out, too. Mea culpa.

> Ok, so we should introduce another kinds of feature which will only
> grab usage-requirements? Now a question: you have
> <dependency>@/boost, there are top-level usage-requirement in
> boost. But one library has additional usage-requirements. What do
> you get when specifying <dependency>/@boost? All
> usage-requirements, or top-level ones?

Well, I'm not sure. For the time being, I only need the <include>.
property of top-level boost. I can live with the rest of the
requirements introduced by boost now.
But I think it would be better if one could "switch" certain parts of
boost "on" per explicit request.

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


> Not to me, but I'm not a fresh user anymore ;-). The original idea
> is that "bjam --v2 clean" removes all targets that were created
> with "bjam --v2". Do you propose that only targets in current
> project are cleaned? How would you clean all the created targets?
> With some command line options?

mmh. That's complicated. For my projects, I often want to rebuild
certain sub-libraries (like liba example) in order to have fresh

> BTW, seems I'm changing mind right now. In my project, I have a
> global source installation of boost, which is used when building.
> If running "bjam --v2 clean" in working copy cleans boost as well,
> this is indeed quite annoying.

Well, when the <dependency> behaviour has changed, then bjam --v2
would not generate any targets in this case. Therefore, no need for a
special option.


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



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