Boost Python library suffix change
Hello, 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. While I could apply this change to Boost.Python only, it seems more natural to patch Boost.Build itself, in which case any library whose build logic uses `python.jam` would also be concerned. Again, as far as I can tell, this only concerns the Boost.MPI Python bindings, but perhaps I'm missing some. So if you are concerned, please speak up, so we can discuss any necessary changes. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
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. - Adam
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
On 09.02.2018 06: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.
Done by whom ? Having downstream maintainers change library names introduces problems for users who need to deal with different library names on different platforms. And it also creates problems for downstream maintainers themselves, as they not only need to rename libraries, but also need to change code (such as the auto-link support that needs to be aware of the library names). Dealing with it inside Boost's own build logic is definitely the best solution for this. (Note that I always argued along a similar line for modularizing Boost packages, which also results in different package structures for different platforms / distributions, so dealing with the problem inside Boost instead of pretending the problem didn't exist would be beneficial to everyone.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (3)
-
Adam Majer -
rleigh＠codelibre.net -
Stefan Seefeld