Re: [boost] Just another GSoC project idea: Create a Bjam clone based on the Boost libraries

Subject: Re: [boost] Just another GSoC project idea: Create a Bjam clone based on the Boost libraries
From: Stephen Kelly (hello_at_[hidden])
Date: 2014-02-16 07:44:13

Boris Schäling wrote:

> On Sun, 16 Feb 2014 09:50:56 +0100, Stephen Kelly <hello_at_[hidden]>
> wrote:
> 
>> [...]The blocker to moving to CMake is acceptance of it as a goal by the
>> boost
>> community. That's not something for a GSoC to resolve.
> 
> Steve,
> 
> do you know whether this is blocking the next release of the Boost
> libraries (1.56.0)? 

I don't understand the question. I can't tell you anything about what is or 
is not blocking Boost 1.56.0.

My impression that moving to CMake is not a goal for the Boost community 
come from mails like these:

 http://thread.gmane.org/gmane.comp.lib.boost.devel/248928/focus=248956
 http://thread.gmane.org/gmane.comp.lib.boost.devel/248928/focus=249009
 http://thread.gmane.org/gmane.comp.lib.boost.build/26227/focus=26252

Clearly, even if some people want to move to CMake, others do not. I am not 
here to convince anyone.

I designed and implemented many features in CMake 3.0 (due RealSoonNow) 
specifically for boost use-cases, eg INTERFACE_LIBRARY:

 http://www.cmake.org/cmake/help/git-next/manual/cmake-buildsystem.7.html#interface-libraries

The innuendo on the boost.build list that a CMake migration would go 
anything like the migration to fractured (not modularized!) git repos is 
unfounded. Technically, there are no blockers. The only blocker is that it 
is not actually a goal of Boost as far as I can tell, and no one is 
championing changing that (I am certainly not volunteering to attempt to 
convince anyone). If someone decides to champion that, the technical backing 
is there. I expect there are minor issues to solve which we have not solved 
yet, but I have no reason to think that there are blockers.

Thanks,

Steve.