Re: [boost] Boost building with CMake

From: Eric Niebler (eric_at_[hidden])
Date: 2007-05-09 12:05:55

Bill Hoffman wrote:
> Hi, 
> 
> 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.

Wow! This is a very generous and exciting offer. Thanks, Bill!

> 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.

This is vital. We shouldn't attempt a switch unless we have reasonable 
assurances that CMake meets (or can be made to meet) Boost's needs. I'm 
encouraged by your offer, and by Doug Gregor's positive experience 
porting Boost to CMake a few years ago.

I guess the first step would be to see if there is interest in the Boost 
community for switching away from our custom build solution to one that 
is more industry standard. (Is there? I'm interested. That makes one.) 
And then someone familiar with Boost's build system to put together a 
list of basic requirements, and go over it with a CMake expert.

I guess I can start the list, and others can chime in. This is from 
http://www.boost.org/tools/build/v1/build_system.htm#design_criteria:

     *  A developer adding a new library or test program must only have 
to add simple entries naming the source files to a text file, and not 
have to know anything about platform specific files. The developer 
should not have to supply header dependency information.
     * There should be a very high likelihood of builds succeeding on 
all platforms if a build succeeds on any platform. In other words, a 
developer must not be required to have access to many platforms or 
compilers to ensure correct builds
     * A user or developer adding support for a new platform or compiler 
should only have to add to a single file describing how to do the build 
for that platform or compiler, and shouldn't have to identify the files 
that will need to be built.
     * The build should rely only on tools native to the platform and 
compiler, or supplied via the boost download.
     * The details of how the build is done for a particular platform or 
compiler should be appropriate for that platform.
     * It should be possible to build multiple variants (e.g. 
debug/release) of a single target.
     * It should be possible to build multiple variants of multiple 
targets with multiple compilers from a single build command.
     * The build tools must be able to handle Boost growth issues such 
as identified in Directory Structure proposals and discussion.
     * Support for dynamic and static linking should be included.
     * It should be relatively straightforward to add support for a new 
compiler. In most cases, no modification of files used to describe 
existing targets should be required.
     * Support for compiler- and variant-specific configuration for each 
target
     * It should be possible to build targets into a directory unrelated 
to the source directories (they may be read-only)

I'd also add:

* Ability to cleanly integrate 3rd party tools (eg. so that we can use 
CMake to build Boost's documentation, which uses doxygen, docbook, 
xsltproc, Apache fop, etc., etc.)
* support for Boost's automatic linking feature.
* Ability to define custom build variants, (eg., so I can build a 
library with FOO defined, and the resulting lib gets a different name.)
* Easy to add tests: compile, run, link, compile-fail, link-fail
* User's can configure multiple toolsets to build with, even multple 
different versions of the same toolset (eg, gcc-4.0, gcc-4.1).

That's just off the top of my head.

> 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 certainly greases the wheels.

> I can see this happening in two ways.  One would be for a CMake developer
> to create initial cmake files for boost, and get the basics working. Then,
> the work would be turned over to the Boost community.  The other way
> would be to have a boost developer create the build files with help and 
> support
> from the CMake community.  Either way works for me.  Of course,
> no one will want to do anything unless there is a commitment to
> actually use CMake.

After we have a list of basic requirements we should have a clearer idea 
of whether CMake can work for us. Better to find the obvious 
showstoppers before spending 2 weeks on a port!

Of course, committing to use CMake is not something any one person in 
Boost can do.

> I will stay on this list while you decide, and answer any questions about
> CMake that may come up.
> 
> Thanks, and I look forward to working with the boost community in
> the future.

Thanks. This certainly gives us something to chew on.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com