From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-05 06:12:06
> > 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.
The problem that to determine all usage requirements, including those for
Boost.Python, for example, you have to try building everything in Boost. It
won't cause real bulding, only "virtual" targets will be created. But still,
Python will be required.
> But I think it would be better if one could "switch" certain parts of
> boost "on" per explicit request.
What about <dependency>@/boost <dependency>@/boost/test
The first will bring global usage requirements, the second one -- for
> > 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
Isn't cleaning *everything* needed sometimes?
> > 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.
Alas, for my case global Boost installation has some libraries to build, and
current "clean" will erase them all. OK, need to think...
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