Re: [boost] Boost Python library suffix change

Subject: Re: [boost] Boost Python library suffix change
From: rleigh_at_[hidden]
Date: 2018-02-09 11:30:48

On 2018-02-09 11:18, Adam Majer via Boost wrote:
> On 02/07/2018 03:20 AM, Stefan Seefeld via Boost wrote:
>> I'm proposing a naming change that affects all libraries that use the
>> `python.jam` build logic, i.e. Boost.Python, as well as libraries
>> providing Python bindings (as far as I can tell, this is only 
>> Boost.MPI,
>> but perhaps I'm missing some).
>> 
>> At present, the Boost.Python build logic produces a library named
>> "boost_python", if built with Python2, and "boost_python3", if built
>> with Python3. I'd like to change that so the actual Python version
>> suffix (e.g. "27" for Python 2.7) is being used. Not only would this
>> simplify / unify naming conventions, it also allows users to collocate
>> libraries compiled against multiple Python versions more easily.
> 
> 
> I think this is already done in cases where this is required. For
> example, in openSUSE:Factory we have,
> 
> /usr/lib64/libboost_python-py2_7.so.1.66.0
> /usr/lib64/libboost_python-py3.so.1.66.0
> 
> And in Debian
> (https://packages.debian.org/sid/amd64/libboost-python1.62-dev/filelist)
> 
> /usr/lib/x86_64-linux-gnu/libboost_python-py27.a
> /usr/lib/x86_64-linux-gnu/libboost_python-py35.so
> /usr/lib/x86_64-linux-gnu/libboost_python-py36.so
> 
> so I'm not sure what is the target audience if the distributions are
> already doing this anyway. Everyone will just have to adapt their code
> (including distributions' build scripts) because of Boost library 
> changes.

The distributions use different conventions, which makes supporting 
Boost's python libraries
in CMake FindBoost a nightmare.  And likewise in any other downstream 
consumer of the Boost
Python libraries; right now you need to hardcode a bunch of 
distribution-specific
assumptions, and it's quite horrible and very fragile.

"Everyone will just have to adapt their code".  Yes, they will, but if a 
one-time break
results in consistent conventions across the board which allow portable 
use of the Boost
Python libraries with the same naming on every platform, that will be a 
big gain.
The distributions only added the suffixes because they had to do so in 
the absence of the
Boost upstream setting a policy from the start, and they had to deal 
with supporting
multiple Python versions.

Having the 2.x version be "unprefixed", "2_x" "2x" and the 3.x version 
be "3" "3_x" "3x"
etc. is really difficult to deal with.  In particular, we can't make any 
assumptions about
the conventions missing a minor version, like "unprefixed", "2" or "3", 
so we have no way to
determine which python libs they are compatible with and this can lead 
to a nasty mess when
you want to find the Boost Python library for a specific Python version. 
  So my 2¢ would be
to recommend that you always require a minor version, like "2x", "3x" 
etc. so that there is
never any ambiguity.

Regards,
Roger