Subject: Re: [boost] [CMake] what to do now?
From: P F (pfultz2_at_[hidden])
Date: 2016-04-13 19:29:51
> On Apr 13, 2016, at 5:54 PM, Stephen Kelly <hello_at_[hidden]> wrote:
> 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).
Yet but it seems to be just putting lipstick on a pig. Boost should move to being able to be built in a simple and modular way and not require esoteric build tools, which will be a greater benefit to boost users.
>> I started writing a cmake(including testing using
>> travis and appveyor) for Boost.Config here:
>> 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.
Yes, it also depends on type_traits in test/math_info.cpp as well.
> 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
> Let's party like it's 2013! \o/
I do remember discussion about this a couple years ago and as I recall, they didnât go so well.
> Be careful - you're about to get into a discussion of what a dependency is.
What I mean by dependency is what is needed to fully build, test, and install the library. I think that is pretty straightforward.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk