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
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#int...
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.