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-11 23:07:58

AMDG

On 3/11/19 4:25 PM, Peter Dimov via Boost wrote:
> Steven Watanabe wrote:
> 
>> a) The extension should be stripped unconditionally: lib-names =
>> $(lib-names:S=) ;
> 
> Doesn't seem so simple. I stripped the suffixes in boost-install, then
> tried to `boost_install boost_zlib` in the Iostreams Jamfile when
> ZLIB_SOURCE is set, but it doesn't work, because the target isn't called
> `boost_zlib`, it's `boost_zlib.1`.
> 

IOStreams shouldn't refer to boost_zlib.  It should use /zlib//zlib
conditioned only on NO_ZLIB/NO_COMPRESSION.  I'm not certain that
this will work in all cases, right now.  It should, correctly, do
nothing when there is no zlib at all, but I'm not sure what it
will do for pre-built libraries

Actually, I take that back.  I never considered the possibility
of users referring to targets other than /zlib//zlib.  If I
make /zlib//<whatever-was-given-as-build-name> a visible
target, I'll be able to fix some long standing issues
that I've been ignoring, i.e. what happens when multiple
projects specify different build-names.  For now, however,
use /zlib//zlib.

>> > 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).
> 
> Wouldn't it hit the `errror` at
> 
> https://github.com/boostorg/build/blob/develop/src/tools/zlib.jam#L162
> 
> ?
> 

No.  is-default is true.  It will arbitrarily select
the first one to be called, which is fine since all
the uses inside Boost should be identical.

In Christ,
Steven Watanabe