Re: [jamboost] [V2] Some usage results

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-05 03:00:09

Hi Jürgen,

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

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

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 ;-)

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

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?

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

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

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?

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.

- Volodya