On 12/27/2010 6:12 AM, Daniel Pfeifer wrote:
Am Sonntag, den 26.12.2010, 23:35 -0500 schrieb Eric Niebler:
On 12/26/2010 11:17 PM, Rene Rivera wrote:
The fact that "there aren't enough people" to make a cmake version possible should be an indication that it should be reconsidered. If it's not possible for *one* person, working part time, to create and maintain the build system, it's already failed.
I don't think there is even one person actively working on it currently, and there hasn't been for some time. We've all been distracted with other things, including the guys from Kitware. IMO, we desperately need a modularized-Boost-CMake-build "guy". Volunteers would be appreciated.
What exactly is the problem with CMake?
No problem at all.
Could you describe the role of this "CMake-guy" in more detail?
There are several facets to this, and the first job is in figuring out how far to go. 1) There already was CMake support in Boost but it was removed because it was unmaintained. A "CMake-guy" could simply assume the responsibility of maintaining this separate build system across all of Boost. In this scenario, we leave the existing testing and release procedures in place. 2) A more ambitious plan is to modularize boost, put each library into its own git repository, and port *that* to CMake. I was working on that until I got busy with other things. If someone were interesting in running with this, I could help them get up to speed. The benefits of this would be a very nimble and flexible Boost library development ecosystem. The idea is very appealing to me. 3) Ryppl: this project had (2) as a sub-goal, but added a top-level tool that took meta-data about project dependencies (in git repositories), downloaded, built, installed, and tested everything. It was to be based on git, CMake, and python packaging support. We got it to the point where it could download, build, install and uninstall packages and resolve some simple dependencies. It got hung up on resolving more complicated dependencies, which is hard problem in the general case. It's doable, but in the end, we just didn't have enough free time. In all cases, there is also the issue of migration, how it effects testing, release procedures, trac, the website, etc. etc. It's acceptable so simply say it doesn't effect it at all and simply ship CMake as an optional alternate build system. But a "CMake guy" would have to commit long-term to maintaining it. -- Eric Niebler BoostPro Computing http://www.boostpro.com