On 7/19/2017 10:29 AM, paul via Boost wrote:
On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write:
"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."
it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.
I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).
CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are.
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
Actually, trying to support multiple variants and prebuilt libraries complicates things. Which is why cmake doesn't support mutliple variants in the same build tree well, and boost build doesn't support prebuilt libraries that well. Of course, there is always workarounds. In bjam, you just create a custom variable to where the prebuilt binary is, and the user needs to pass that in for every dependency. In cmake, you just create multiple build directories for each variant you have. However, the workaround for cmake can be automated across many different libraries, but the workaround for boost.build cannot, as the custom variables could always be different.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost