Boost Python library suffix change

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost Python library suffix change

Boost - Dev mailing list
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...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost Python library suffix change

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost Python library suffix change

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost Python library suffix change

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost