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