Re: [boost] Boost building with CMake

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-05-09 14:28:26

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