Vicente J. Botet Escriba wrote:
this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming
Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries.
Is CMake build ready for review? If no, what is missing, not working yet, ...?
I was interested in modularization because I wanted to make a small library and have it self contained so it doesn't have to be in the boost tree, but would have that option in the future. Then I came upon the cmake stuff and asked the question. Then I thought I remembered that the cmake stuff was in the boost tree but when I looked I didn't find it there. I found it in the GIT tree. So as things stand now, cmake build/test of boost is not part part of boost itself. It's not a required tool. So I can't see why a review would be necessary. What if it fails the review - would I be prevented from using it on my own machine? If things evolve and a significant number of people start to prefer it over the current system, we can look at the issue as to whether we have to choose and if so what should we choose. a totally separate issue - the GIT tree seems to clone the trunk - wouldn't it be better if it cloned the release branch? Robert Ramey