Subject: Re: [boost] Just another GSoC project idea: Create a Bjam clone based on the Boost libraries
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-02-16 10:31:18
On 2/16/2014 7:44 AM, Stephen Kelly wrote:
> 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.
I have found understanding bjam and Boost Build largely impenetrable
based on its documentation. I am not criticizing its functionality or
how well it works for the vast majority of normal cases. It is when one
needs to do something outside of the norm that I have found it very
difficult, ie. actually writing bjam files with an undestanding of how
they fit in with the Boost Build system.
I know nothing about CMake. If it could provide the functionality that
bjam/Boost Build provides in an understandable and flexible way so that
it would be easier for non-experts to manipulate the build of libraries,
test cases, documentation, I would love it as at least an alternative to
current Boost Build.
Without knowing anything about CMake my one worry about it is that it is
a generalized build system and I do not know if it could be made as
flexible as Boost Build in being tailored toward Boost developers.
This is just purely my personal opinion and I have no idea how the
majority of Boost library developers or users feel about it, much less
the acknowledged leaders in the Boost community of developers.