Re: [boost] [Release] Boost 1.70.0 Beta 1 Release Candidate 2

Subject: Re: [boost] [Release] Boost 1.70.0 Beta 1 Release Candidate 2
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2019-03-10 17:56:52

AMDG

On 3/10/19 11:33 AM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
> 
>> > The purpose of that incrementing library-id, as far as I can infer,
>> is > to enable two libraries to have their own private zlib dependencies.
>>
>> That's not really correct.  The reason for the library-id is to make
>> sure that target alternative selection only
> happens at the top level on the /zlib//zlib target.
> 
> So it's intended for cases like
> 
> using zlib : 1.2.7 : <source>C:/Devel/src/zlib-1.2.7 : <toolset>msvc ;
> using zlib : 1.2.7 : <source>/opt/src/zlib-1.2.7 : <toolset>gcc ;
> 
> ?

Yes.

> 
> Either way, in general, when I see lib1 having a CMake dependency on
> foo.1 and lib2 having a dependency on foo.2, ignoring the suffix doesn't
> seem correct.
> 
> I could add a specific check for `zlib.*` and `bzip2.*` but this will
> only work for Iostreams.
> 

a) The extension should be stripped unconditionally:
    lib-names = $(lib-names:S=) ;
b) foo.1, foo.2 etc, should be sorted out by foo.cmake.  The
   exact suffix used is highly unstable and should not be
   used in any way outside of a single run of b2.  The choice
   will need to be made based on the original requirements,
   instead. (<toolset>gcc or <toolset>msvc in your example.)

> What's the intended path forward (in general, not specifically for the
> CMake configurations) when a second Boost library wants to use zlib and
> bzip2?
> 

I'm not sure.  Before boost_install, I would have said
that it will Just Work (TM).  I still think that should
be the goal: specify the dependency normally, and let
boost_install and/or zlib sort out exactly what needs
to be installed and how.

In Christ,
Steven Watanabe