1 |
Hello, everyone. |
2 |
|
3 |
As you probably don't know, Justin lately noticed that we're carrying |
4 |
some ugly hacks in Python 3.2+ where we diverge from upstream and break |
5 |
binary compatibility for the sake of 'aesthetics'. While we're not yet |
6 |
ready to kill them completely (the current work being kept |
7 |
in python-soabi-cleanup branch), here's a batch of patches that clean up |
8 |
python-utils-r1 getters and future-proof them for restoring ABIFLAGS. |
9 |
|
10 |
In order: |
11 |
|
12 |
1. updates tests to use py3.4 rather than py3.3, |
13 |
2. prepares python_export() for spawning python, |
14 |
3. gets includedir from python, |
15 |
4. gets library path from python, |
16 |
5. gets site-packages path from python, |
17 |
6. adds API to get python-config path, |
18 |
7. updates python_wrapper_setup() appropriately. |
19 |
|
20 |
Summarizing, when the changes are done, the eclass is going to hardcode |
21 |
less variables and call Python more often. Implications for ebuilds: |
22 |
|
23 |
a. calling the relevant getters will require build-time dependency on |
24 |
Python. Not that it really made sense without it -- why would you get |
25 |
library path or include directory if you're not going to link or compile |
26 |
against Python? Or why would you get sitedir if you're not going to |
27 |
install modules (=> byte-compile them)? |
28 |
|
29 |
b. ${PYTHON}-config hacks need to replaced by |
30 |
$(python_get_PYTHON_CONFIG). Direct python-config calls are still fine |
31 |
(wrapped by the eclass). The GNOME ebuilds which used the former syntax |
32 |
directly are already fixed in the branch. |
33 |
|
34 |
c. The getters will get a little slower. However, that shouldn't be |
35 |
really important since they are forbidden during metadata regen, and in |
36 |
ebuild runs we can expect the relevant Python version to be spawned |
37 |
anyway (=> hot cache). |