On Fri, Jun 01, 2012 at 09:44:24AM -0400, Nat Linden wrote:
But I'll drop this because I'd forgotten that CMake is going to make all the above moot.
I look forward to seeing how (I assume they _will_) the CMake efforts handle all the variants that Boost provides/allows, and the abysmal syntax they will invent to make it happen. I mean, there's not much of a difference between: * b2 toolset=msvc-11.0 --prefix=C:\Boost address-model=64 and * cmake -G "Visual Studio 2012 Win64 Solution" -DCMAKE_INSTALL_PREFIX:STRING=C:\Boost Except of course that the former is extensible, homoegeneous, and doesn't have all that weirdo string cache shenanigans and requiring fresh build directories and manual cleanout of artifacts if you're ever insane enough to do in-tree builds. I also look forward to the Sisyphusean struggle to support ancient versions of CMake vs. actually being able to express things in your build scripts. Boost.Build has a gigantic advantage in being trivially bundlable with the Boost archive and trivially buildable on anything that has a C compiler. CMake is a quite more serious dependency and the binaries provided are small in number and in the case of AIX, doesn't even run due to the instruction set supported by some machines. Silly as it may be, we have signficant competence in Boost.Build and it does what it should excellently. CMake will not make anything moot. It will just make it different. Users are still broken, and they will still need assistance and documentation. The difference is that no-one that pushes the CMake effort will be around to aid them, and no-one will be arsed to grok the build system beyond the bare minimum they need to get their things working. Don't underestimate the rather hidden amount of support that is being done outside of the lists. -- Lars Viklund | zao@acc.umu.se