Inspired by the recent discussion regarding CMake, I've spend some more time looking at this. As a result, I've done the following. a) I experimented with using CMake in the more customary manner in my canonical project Safe Numerics - (see Boost Library Incubator). The current version does distribute CMakeLists.txt around the subdirectories of the library root. My original objections to doing this were assuaged when I realized that boost build does the same thing. That is I typically have Jamfiles in side of test, example and sometimes other directories. b) One of the features that I much like about Boost Build is the possibility of arbitrary nesting of Jamfiles. This permits one to build/test a portion of one's library (e.g. test, example) as well as the whole library. For a large library this is indispensable. In spite of what many people think, this is not easily supported with CMake. However, I have found that with some extra effort, it is possible to support this to the extent we need it. So in this project ONE CAN BUILD (actually create an IDE project or makefile that builds) ANY OF THE "SUBPROJECTS" (TEST, EXAMPLE) AS WELL AS THE LIBRARY "SUPERPROJECT" c) CMake is indispensable to me: * it creates IDE projects for "any?" platform. I use IDE alot. * everyone else uses it - so it makes it easier to promote my work to others. * it's easier to make work - still a pain though * There is lots of information, around the net about how to use CMake, how easy it is etc. Although they help when you're looking for an answer (which is all the time) - they really betray how complex, arbitrary and complex the system is. * It has an almost of idiot proof GUI version which I use a lot. I really like this. * CMake is well maintained and supported by it's promoters. d) Boost Build * either just works (great!) or doesn't. If it doesn't it's almost impossible fix without getting help * I've never run across anyone outside of boost who uses it. It makes it harder to promote my work. * It's natural to compose projects into "super projects" * it's almost impossible to integrate with and IDE. At one time, I had things setup so I could debug executables created with boost build with the Visual Studio IDE and debugger. But it was just too fragile and time consuming to keep everything in sync. * it has a lot of "automatic" behavior which can be really, really confusion. A small example: you've got multiple compilers on your system. When it discovers this, it just picks the "best" one and you don't know which one you got until the project builds (or not). I'm sure this was implemented this way to make usage of boost build "simple" but it has the opposite effect. Much better would be fail immediately with a message "multiple compilers found:... use toolset=<compiler name> to select desired one." Some Conclusions - I'm trying to not make this a rant a) The ideal, platform independent build system does not yet exist. I guessing it never will. I'm sure it won't happen in my life time - but then I'm 68 - maybe you'll get lucky. b) Both systems are much more fragile, complicated and opaque than their promoters try to make you believe. It's not that they're lying, they truely believe in their own stuff. There is much re-invention of the wheel - The each created their own (half-assed) little language for goodness sake!!! c) Neither has really resolved the issue of nested projects in a clear way. Boost Build probably does or can do this. CMake has a system of "packages" and a whole 'nuther layer about "finding" them. Assuming it can be made to work - given the amount of time I've invested in CMake, I should know how to do this by now. d) I think it's time for Boost to be a little more open about tolerating/encouraging alternative build systems. I think our documentation approach is a model. Yeah it's a hodgepodge. But the various ways of doing pretty much work and generally don't stop working and we don't have to constantly spend effort bringing things up to the latest greatest system (which we couldn't agree upon anyway). We have libraries which have been going strong 15 years - and people can still read the docs. e) We should find some way to recognize those who have made the system work as well it has. Doug Gregor (boost book), Eric Niebler, Joel Guzman (quickbook). Vladimir Prus, Rene Rivera, Steve Watanabe. I know there others but these come to mind immediately. Note that I have only addressed the issue of library development which is my main interest. I'm really not seeing this issues related to users of libraries. In particular, CMake has the whole "find" thing which I'm still not even seeing the need for. If I want to use a library, I can build the library and move it to a common place with the headers, specify the include directory and I'm on my way. I'm sure someone will step up to enlighten me on this. Robert Ramey