Re: [boost] [CMake] what to do now?

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:
>> 
>> 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. 

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
>> libraries). 
> 
> 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.

> 
> Thanks,
> 
> Steve.
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost