Subject: Re: [boost] Boost Python library suffix change
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
>> 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,
> And in Debian
> 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
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
assumptions, and it's quite horrible and very fragile.
"Everyone will just have to adapt their code". Yes, they will, but if a
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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk