Re: [boost] Why Boost.Build?

Subject: Re: [boost] Why Boost.Build?
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2011-03-30 13:43:36

On 30/3/2011 5:51, Steven Watanabe wrote:
> I think "everyone" is a huge exaggeration.
> The kind of tasks for which it matters should
> not be pervasive. If they are, then Boost.Build
> has failed much more fundamentally, or it's
> simply being misused.
>

I think this is exactly the point, it did fail much more fundamentally.

 From a perspective of a user of a library the build system of the 
library needs to double as the library installer. So the function of a 
build system which is probably used the most is:

  "make && make install" or
  "./configure && make && make install"

if this commands (without any additional parameters!) doesn't find all 
external libs and the systems default toolchain, I consider that a very 
grave bug which could sway me to not depend on this library at all.
Then I need some method to "link" against the lib (or include it for 
header only libs) which should not be much more onerous than something 
along the lines of

FindPackage (Boost)

again without any Path or similar parameters.

For a developer (and in case of open source libs the developers were 
mostly users first) the next function I need is that it integrates 
nicely with my work environment.
So a function like CMakes generators which generate Project files for 
common IDE's which also represent the structure of the lib, is a bit 
more than only a nice to have, because I would really resent having to 
do this manually.

Next Features in order of importance: Test integration, (Binary) 
packageing (Multiple configs come into play here), interpackage 
dependency management.

All just my very humble opinion

regards

Fabio