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