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 16:58:48

On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
> 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.

But it only searches along the default compiler paths and additional paths
added in the build script. There is no way for me to inform bjam that I
installed my dependencies in another directory. 

That is, I installed my dependencies in /deps. So how do I tell boost to look
for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find
them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A
custom variable for each one.

That is just one issue, the other issue is that it doesn't provide usage
requirements for prebuilt libraries. I install a library with Boost.Build, but
even even if downstream libraries are using Boost.Build, there is no
information available about the its usage requirements.

And of course, all this could be added to Boost.Build, but it would run into
the same complexities cmake would if it were to add support for multiple
variants within the same build tree.