Re: [jamboost] [V2] Some usage results

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

-----BEGIN PGP SIGNED MESSAGE-----
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 
start. 

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+ZcxzljbJ/LLrxrYRAmsdAJ9FPMUohrdfBAXnNsBBLhmcyZzv5wCcCo2+
CpQiks5CNlg07DGT+HMm7l0=
=1UMU
-----END PGP SIGNATURE-----