On 7/21/17 8:57 AM, Stefan Seefeld via Boost wrote:
On 21.07.2017 10:21, Thomas Heller via Boost wrote:
Hi list,
After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake.
Mostly, yes. And in addition, people are very polarized (even more so as a result of this ongoing discussion). So to frame the question as "should we stay with Boost.Build or should we move to CMake" is extremely counter-productive.
We need a way to continue to draw from the wealth of expertise encoded in the existing Boost.Build infrastructure as well as the community around it, while at the same time being open to change (in general, not just towards alternative build tools). To invoke a higher authority to decide to get out of this stalemate is foolish, as it entirely ignores both how Open Source works in general (you can't coerce people into doing things they aren't motivated to do to begin with), as well as the real reason for the stalemate: it's due to an artificial dichotomy: either Boost.Build or CMake, globally, for everyone at once.
Here is (once again) how I would approach this instead:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals).
This is already in place. I all the time. Here is what I do: a) I make a change to some library b) I cd to the test directory of the library c) I invoke b2 to build and run the tests (I do this through the library_test macro in boost/tools, but that's not essential). d) the b2 build any dependent libraries and runs the tests of the library I'm working on.
* Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic.
This is what the top level build logic does. I once posted a simple shell script which would do exactly that. I turned out that this didn't work because the top level system had some library specific logic in it to accomodate some libraries which "do their own thing". I noted at the time that it was a mistake to do this and that library authors should have committed to boost requirements rather than the other way around.
* With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
This is indeed possible. In fact its quite easy. I created CMake CMakeList.txt files for the serialization libary - which has a very complex testing regimen. It's also not header only and supports a lot of variants, static, debug, the works. The safe numerics version even supports the CDash functionality which would be very useful to boost. I didn't like the way CMake implemented though. I did this because I wanted to be able to create an IDE for editing, testing and debugging the library. It's very easy for anyone who is interested to invoke CMake in the serialization directory, build and IDE and open it up and see what you get. So far as I know - only one person has actually done this.
Does this process appeal to anyone ?
Makes total sense to me. There are a couple of I haven't addressed because I haven't need them. a) The CDash functionality - needs a much better solution c) The CPack - packager - I have never figured out the utility of this c) FindBoostSerialization library. THis might be interesting to users or maybe not. When I use Boost in a CMake project I use FindBoost. This doesn't really work, but with some horsing around it can be made to work. There are lots of opinions on this thread amounting to saying "Here is what needs to be done - Developers (or someone else) should be forced to do it". This has gone nowhere and is not going anywhere. The SC can make any pronouncement it wants, but that's all its going to be until someone actually DOES something. The closed I've seen are my pages on CMake in the incubator and Peter Dimovs CMake proposal (which I haven't had time to study). Other than that ... nothing of substance. Robert Ramey