Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: paul (pfultz2_at_[hidden])
Date: 2017-07-19 14:29:02

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. 

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.