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