On May 9, 2007, at 12:35 PM, David Abrahams wrote:
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion.
Whoa; that's a very significant development.
I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
That's huge.
Yes, this is wonderful.
I want to discuss our requirements, though, and make sure that they will actually be satisfied. One question on my mind: how much of what Boost.Build provides is already in the CMake system, and how much would have to be implemented on top of that, in CMake files?
We'll have to build some of the more obscure things we do on top of CMake (e.g., the BoostBook toolchain) via its custom commands, of course.
If there's a lot that would have to live outside of CMake itself, the value of a switch would be reduced.
Yes and no. At least we'd be building on a well-documented core system, and the main important features of a build system---building and installing libraries---would be in the CMake core. Jam was a bit of a let-down because the base functionality is so weak (forcing us to re-build most of it in BBv1 and BBv2) and the Jam language itself is rather under-documented.
My main concern is that we satisfy most of http://www.boost.org/tools/build/v1/build_system.htm#design_criteria
The only one I'm not sure about is: - It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command. I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
Unfortunately I don't think Boost can commit to using CMake until we see that it can work for us. That would mean at least getting the basics working. Do we have a chicken-and-egg problem here?
I for one am very grateful for the offer, and hope that we can take advantage of it.
I think someone from Boost needs try a proof-of-concept system with CMake before we ask for any assistance from Kitware. It does not make sense to ask a Kitware developer to write CMakeLists.txt files (the equivalent of our Jamfile.v2s) for all of the Boost libraries; that's better handled by someone familiar with BBv2 and familiar with the structure of Boost libraries. Of course, that means we need an intrepid volunteer to start converting Boost to CMake, and we'll see where we run into problems. Any takers? - Doug