P F wrote:
Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.
I really recommend trying to generate cmake packages for the sake of users of boost. Once you have that, porting any boost library to use cmake is much easier - but it is a very different task and requires very different buy-in from people and is a much more significant change for the boost community. What I proposed in that thread is for the benefit of boost users and is completely compatible with current boost community values (does not propose moving away from boost.build, which is a too-controversial topic).
I started writing a cmake(including testing using travis and appveyor) for Boost.Config here:
https://github.com/pfultz2/config
But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config.
I guess you're referring to test/limits_test.cpp:#include <boost/core/lightweight_test.hpp> in Boost.Config. The good news is that some of the cycles which I described previously are no longer present (due to http://lists.boost.org/Archives/boost/2015/01/219121.php I suppose). I made updated diagrams of this but haven't posted them yet. But I was only interested in cycles from public headers, not tests.
Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries).
Let's party like it's 2013! \o/ Be careful - you're about to get into a discussion of what a dependency is. :) Thanks, Steve.