[gentoo-dev] Re: [PATCHES] python-utils-r1.eclass: Getter cleanup & ABIFLAGS preparation

[Mike Gilbert]

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

This series looks good to me. Thanks for the work.