Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-19 16:39:34

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
>