|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk