[gentoo-dev] python versioned libraries or not

[gentoo-dev] python versioned libraries or not

[heroxbd]

Dear all,

I have only one python-2.7 on my system. Simple and stupid.

After boost ebuild is converted to python-r1, libboost_python.so is
renamed to libboost_python-2.7.so. This is all cool about python-r1 for
multiple python implementation support.

At the same time, I don't need this feature. I have a couple of
Jamroot's which append "-lboost_python" to LDFLAGS, and I have to
manually specify "-lboost_python-2.7". Moreover, libraries depending on
boost.python, e.g. Boost.NumPy[1], searches for boost_python and
boost_python-mt only. I am forced to patch the build system to pass
"-${PYVAR}" to it, which is tedious.

I am looking for a way out. Candidates are,

    1. scan all python versioned libraries and symlink them to
       unversioned one. Question: hints to do it systematically in
       portage? Is there a helper available like python-exec?

    2. python-single-r1 is ready for use, but it requires manipulating
       the boost ebuild to change from python-r1, if I want a
       python-single-r1 blessed boost. Question: How about merging
       python-single-r1 with python-r1 and controlling by a global USE
       flag "python-single". When "python-single" is set, all ebuilds
       inheriting python-r1 behaves as if being with python-single-r1,
       so that all python versionings on executables and libraries are
       disabled.

    3. or something I missed

Comments?

Benda

1. https://github.com/ndarray/Boost.NumPy

Re: [gentoo-dev] python versioned libraries or not

[yac]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On Thu, 05 Dec 2013 13:32:09 +0900
heroxbd@gentoo.org wrote:

> Dear all,
> 
> I have only one python-2.7 on my system. Simple and stupid.
> 
> After boost ebuild is converted to python-r1, libboost_python.so is
> renamed to libboost_python-2.7.so. This is all cool about python-r1
> for multiple python implementation support.
> 
> At the same time, I don't need this feature. I have a couple of
> Jamroot's which append "-lboost_python" to LDFLAGS, and I have to
> manually specify "-lboost_python-2.7". Moreover, libraries depending
> on boost.python, e.g. Boost.NumPy[1], searches for boost_python and
> boost_python-mt only. I am forced to patch the build system to pass
> "-${PYVAR}" to it, which is tedious.

Shouldn't pkg-conifg --libs handle this?
 
> I am looking for a way out. Candidates are,
> 
>     1. scan all python versioned libraries and symlink them to
>        unversioned one. Question: hints to do it systematically in
>        portage? Is there a helper available like python-exec?
> 
>     2. python-single-r1 is ready for use, but it requires manipulating
>        the boost ebuild to change from python-r1, if I want a
>        python-single-r1 blessed boost. Question: How about merging
>        python-single-r1 with python-r1 and controlling by a global USE
>        flag "python-single". When "python-single" is set, all ebuilds
>        inheriting python-r1 behaves as if being with python-single-r1,
>        so that all python versionings on executables and libraries are
>        disabled.
> 
>     3. or something I missed
> 
> Comments?
> 
> Benda
> 
> 1. https://github.com/ndarray/Boost.NumPy
> 



---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] python versioned libraries or not

[heroxbd]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

yac <yac@gentoo.org> writes:

> Shouldn't pkg-conifg --libs handle this?

Oh, good idea. But boost doesn't have pkg-config entries.

Then I see this one, an upstream issue

     https://svn.boost.org/trac/boost/ticket/1094

Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] python versioned libraries or not

[Luca Barbato]

On 08/12/13 00:44, heroxbd@gentoo.org wrote:
> yac <yac@gentoo.org> writes:
> 
>> Shouldn't pkg-conifg --libs handle this?
> 
> Oh, good idea. But boost doesn't have pkg-config entries.
> 
> Then I see this one, an upstream issue
> 
>      https://svn.boost.org/trac/boost/ticket/1094
> 

Are you willing to poke upstream again? I'm not sure which problem they
have with pkg-config that a little more awareness wouldn't solve.

lu