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