1 |
Dear all, |
2 |
|
3 |
I have only one python-2.7 on my system. Simple and stupid. |
4 |
|
5 |
After boost ebuild is converted to python-r1, libboost_python.so is |
6 |
renamed to libboost_python-2.7.so. This is all cool about python-r1 for |
7 |
multiple python implementation support. |
8 |
|
9 |
At the same time, I don't need this feature. I have a couple of |
10 |
Jamroot's which append "-lboost_python" to LDFLAGS, and I have to |
11 |
manually specify "-lboost_python-2.7". Moreover, libraries depending on |
12 |
boost.python, e.g. Boost.NumPy[1], searches for boost_python and |
13 |
boost_python-mt only. I am forced to patch the build system to pass |
14 |
"-${PYVAR}" to it, which is tedious. |
15 |
|
16 |
I am looking for a way out. Candidates are, |
17 |
|
18 |
1. scan all python versioned libraries and symlink them to |
19 |
unversioned one. Question: hints to do it systematically in |
20 |
portage? Is there a helper available like python-exec? |
21 |
|
22 |
2. python-single-r1 is ready for use, but it requires manipulating |
23 |
the boost ebuild to change from python-r1, if I want a |
24 |
python-single-r1 blessed boost. Question: How about merging |
25 |
python-single-r1 with python-r1 and controlling by a global USE |
26 |
flag "python-single". When "python-single" is set, all ebuilds |
27 |
inheriting python-r1 behaves as if being with python-single-r1, |
28 |
so that all python versionings on executables and libraries are |
29 |
disabled. |
30 |
|
31 |
3. or something I missed |
32 |
|
33 |
Comments? |
34 |
|
35 |
Benda |
36 |
|
37 |
1. https://github.com/ndarray/Boost.NumPy |