Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk