1 |
On Mon, 03 Dec 2012 10:46:42 -0500 |
2 |
Mike Gilbert <floppym@g.o> wrote: |
3 |
|
4 |
> On 12/3/2012 6:00 AM, Michał Górny wrote: |
5 |
> > Export the best implementation's build dir as BEST_BUILD_DIR, in order |
6 |
> > to avoid clobbering original BUILD_DIR. |
7 |
> > --- |
8 |
> > gx86/eclass/distutils-r1.eclass | 31 ++++++++++++++++++++++++++----- |
9 |
> > 1 file changed, 26 insertions(+), 5 deletions(-) |
10 |
> > |
11 |
> > diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass |
12 |
> > index b1b3f90..db8fe86 100644 |
13 |
> > --- a/gx86/eclass/distutils-r1.eclass |
14 |
> > +++ b/gx86/eclass/distutils-r1.eclass |
15 |
> > @@ -388,6 +388,27 @@ distutils-r1_run_phase() { |
16 |
> > if [[ ${DISTUTILS_IN_SOURCE_BUILD} ]]; then |
17 |
> > popd &>/dev/null || die |
18 |
> > fi |
19 |
> > + |
20 |
> > + # Store them for reuse. |
21 |
> > + _DISTUTILS_BEST_IMPL=( |
22 |
> > + "${EPYTHON}" "${PYTHON}" "${BUILD_DIR}" "${PYTHONPATH}" |
23 |
> > + ) |
24 |
> |
25 |
> Why are you using an array here? To save 1 line of code? |
26 |
|
27 |
Yes, something like that. Plus do not have to invent names for all |
28 |
of them. |
29 |
|
30 |
> Putting the values in an array makes them anonymous for no reason I can see. |
31 |
|
32 |
To be honest, I don't see a reason for them to be non-anonymous. It's |
33 |
not something user should touch. A bit like four variables == four |
34 |
times as much risk of random collision. |
35 |
|
36 |
> > +} |
37 |
> > + |
38 |
> > +# @FUNCTION: _distutils-r1_run_common_phase |
39 |
> > +# @USAGE: [<argv>...] |
40 |
> > +# @INTERNAL |
41 |
> > +# @DESCRIPTION: |
42 |
> > +# Run the given command, restoring the best-implementation state. |
43 |
> > +_distutils-r1_run_common_phase() { |
44 |
> > + local EPYTHON=${_DISTUTILS_BEST_IMPL[0]} |
45 |
> > + local PYTHON=${_DISTUTILS_BEST_IMPL[1]} |
46 |
> > + local BEST_BUILD_DIR=${_DISTUTILS_BEST_IMPL[2]} |
47 |
> > + local PYTHONPATH=${_DISTUTILS_BEST_IMPL[3]} |
48 |
> > + |
49 |
> > + export EPYTHON PYTHON PYTHONPATH |
50 |
> > + |
51 |
> > + "${@}" |
52 |
> > } |
53 |
> > |
54 |
> > distutils-r1_src_prepare() { |
55 |
> > @@ -419,7 +440,7 @@ distutils-r1_src_configure() { |
56 |
> > multijob_finish |
57 |
> > |
58 |
> > if declare -f python_configure_all >/dev/null; then |
59 |
> > - python_configure_all |
60 |
> > + _distutils-r1_run_common_phase python_configure_all |
61 |
> > fi |
62 |
> > } |
63 |
> > |
64 |
> > @@ -435,7 +456,7 @@ distutils-r1_src_compile() { |
65 |
> > multijob_finish |
66 |
> > |
67 |
> > if declare -f python_compile_all >/dev/null; then |
68 |
> > - python_compile_all |
69 |
> > + _distutils-r1_run_common_phase python_compile_all |
70 |
> > fi |
71 |
> > } |
72 |
> > |
73 |
> > @@ -451,7 +472,7 @@ distutils-r1_src_test() { |
74 |
> > multijob_finish |
75 |
> > |
76 |
> > if declare -f python_test_all >/dev/null; then |
77 |
> > - python_test_all |
78 |
> > + _distutils-r1_run_common_phase python_test_all |
79 |
> > fi |
80 |
> > } |
81 |
> > |
82 |
> > @@ -467,9 +488,9 @@ distutils-r1_src_install() { |
83 |
> > multijob_finish |
84 |
> > |
85 |
> > if declare -f python_install_all >/dev/null; then |
86 |
> > - python_install_all |
87 |
> > + _distutils-r1_run_common_phase python_install_all |
88 |
> > else |
89 |
> > - distutils-r1_python_install_all |
90 |
> > + _distutils-r1_run_common_phase distutils-r1_python_install_all |
91 |
> > fi |
92 |
> > } |
93 |
> > |
94 |
> |
95 |
> I haven't run into a situation that patch series is intended to address, |
96 |
> so I don't have any strong opinion on it. If you think it is useful, |
97 |
> fine by me. |
98 |
|
99 |
Well, the common case I can think of is building docs. Although it |
100 |
isn't really necessary to bind that strongly to any specific |
101 |
implementation, doing so allows packages to use compiled modules. |
102 |
|
103 |
-- |
104 |
Best regards, |
105 |
Michał Górny |