At Sat, 29 Jan 2011 12:21:54 +0100, Daniel Pfeifer wrote:
Daniel Pfeifer <daniel@pfeifer-mail.de> Subject: [boost] Distributed Boost with CMake: proposal and volunteering Date: Sat, 29 Jan 2011 12:21:54 +0100 To: <boost@lists.boost.org> Message-ID: <9258a13ec6727bac1f0dc8baa849fc35-EhVcX1dJTQZXRw0RBgwNVDBXdh9XVlpBXkJHHF5ZWC9fUkYLQVx+H1dWXjBeQ0wEXFpZQVlR-webmailer2@server04.webmailer.hosteurope.de> User-Agent: Host Europe Webmailer/2.0 Reply-To: boost@lists.boost.org List-Post: <mailto:boost@lists.boost.org>
Hi all,
I would like to propose my approach to a modularized build of the Boost C++ Libraries with CMake. The project is found on http://github.com/purpleKarrot/Boost.CMake
Ummm... wow! This is certainly a welcome surprise. * Did you do this all by yourself? * Is it based on prior Boost/CMake efforts? * Did you know about the overlapping effort at Ryppl?
The following features are currently implemented: * Aggregate modules from different sources (CVS, SVN, GIT, tarballs, ...). * Build, Test, Install
* Have you verified that it builds, tests, and installs equivalent targets to what is being done by bjam? And if so, how?
* Create a binary installer with selectable components for Windows. * Create a source package (with the modules included) that can do everything in this list (except the first entry). * Create a Debian source package that can be uploaded to a Launchpad PPA where it is built and packaged into many binary Debian packages. * Build Documentation (the usual quickbook-doxygen-boostbook-chain). * Tested on Windows (Visual Studio 10) and Ubuntu (GCC).
* What was the test methodology?
* Precompiled headers (currently MSVC only).
I know what precompiled headers are, but I'm not sure specifically what it means that you're listing them here.
* Build two Boost.MPI libraries on Debian: boost_openmpi and boost_mpich2. * Tests actually make use of Boost's autolinking feature.
Nice.
This tool would allow the following Boost development process: * Each Boost library uses it's own repository (no matter which VCS) * Boost.CMake has a list of modules (or multiple list: eg 'boost' and 'incubating') * A modules definition consists of the information about where to get the source code from. * Boost.CMake can be used to aggregate all modules, run tests, build release packages... * Incubating libraries can be tested before they become an official part of boost.
Very nice!
Please note that I am not proposing a development process. I am just proposing a tool. I am volunteering to extend and maintain the tool so that it can (help to) drive the development process.
Whoa, seriously? Gratefully accepted! However, what I'd really like is to get you and the other stakeholders who are investing in the same thing (e.g. Kitware) on the same page, so that it's not just up to you alone. One of the main goals of the Ryppl project is to use tools that are maintained by more than one or two individual developers.
If you decide that all libraries should use git, I can drop the support for all other VCSs, no problem.
Also, I am happy to implement other missing features.
Let's talk!
In the next couple of days I was going to write some documentation and a tutorial how to migrate the libraries to CMake.
I'm a little confused. From the results you've reported, it sounds like you've already done that migration. So what's left to do? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com