1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
- -----BEGIN PGP SIGNED MESSAGE----- |
5 |
Hash: SHA256 |
6 |
|
7 |
On 06/09/12 04:26 PM, Michał Górny wrote: |
8 |
> On Thu, 06 Sep 2012 14:22:24 -0400 Ian Stakenvicius |
9 |
> <axs@g.o> wrote: |
10 |
> |
11 |
>> So one of the advantages of using python-distutils-ng.eclass for |
12 |
>> building (and building against) python modules is that python |
13 |
>> module dependencies can be guaranteed against the same python |
14 |
>> targets as what you're building for, via the PYTHON_TARGETS use |
15 |
>> expansion. |
16 |
>> |
17 |
>> Unfortunately, one of the drawbacks to this is that dependencies |
18 |
>> are long and ugly. |
19 |
>> |
20 |
>> Since in most cases, any python module in *DEPEND is going to |
21 |
>> have python_targets_*? use deps for each implementation in |
22 |
>> $PYTHON_COMPAT, a helper variable that can be substituted for |
23 |
>> this list would simplify the ebuild. |
24 |
> |
25 |
> Didn't I think of the same thing some time ago? |
26 |
> |
27 |
|
28 |
Not sure; you think of so many different things.. :D |
29 |
|
30 |
|
31 |
>> The implementation in the patch below is probably not the best, |
32 |
>> but I propose it as a starting point. |
33 |
>> |
34 |
>> |
35 |
>> - --- python-distutils-ng.eclass 2012-06-18 10:53:33.000000000 |
36 |
>> -0400 +++ python-distutils-ng.eclass.new 2012-09-06 |
37 |
>> 13:47:28.000000000 - -0400 @@ -59,6 +59,22 @@ # Set to any value |
38 |
>> to disable automatic reinstallation of scripts in # bin |
39 |
>> directories. See python-distutils-ng_src_install function. |
40 |
>> |
41 |
>> +# @ECLASS-VARIABLE: PTUD |
42 |
> |
43 |
> PTUD? Sounds like a verb. Something like 'you should PTUD yourself' |
44 |
> ;D. |
45 |
> |
46 |
> Not that I'm that brilliant to come up with something good but it |
47 |
> should start with 'PYTHON_', I think, and be explanatory. |
48 |
> |
49 |
|
50 |
I wanted it to be short -- this is a convenience variable to be used |
51 |
in *DEPEND; and since it contains Python Target Use Dependencies, i |
52 |
figured the acronym was the best way to go.. |
53 |
|
54 |
PS, '@INTERNAL' is probably not a good tag to set here but i couldn't |
55 |
find documentation on what tags were available; if there's a @READONLY |
56 |
or @CONSTANT that would be best. |
57 |
|
58 |
>> +# @INTERNAL +# @DESCRIPTION: +# Provides the complete expansion |
59 |
>> of python_target_ use depedencies +# from the content of |
60 |
>> $PYTHON_COMPAT ; it can be used as a shortform +# to set or or |
61 |
>> append the use deps of complete python-module +# dependencies, |
62 |
>> ie: RDEPEND="dev-python/foo[${PTUD}]" |
63 |
> |
64 |
> I think it should spell clearer how the string looks like, i.e. |
65 |
> that it is 'pythonx_y?,pythonx_z?,...'. |
66 |
> |
67 |
>> + +mysep= +PTUD= +for impl in ${PYTHON_COMPAT} ; do + |
68 |
>> PTUD+="${mysep}python_targets_${impl}?" + mysep="," +done +unset |
69 |
>> mysep + |
70 |
> |
71 |
> Nice hack with that mysep but I don't like it, sorry. I'd rather |
72 |
> avoid temporary variables here, or use a function and a 'local' |
73 |
> variable. Calling a function in global scope shouldn't be that |
74 |
> bad. |
75 |
> |
76 |
> or just something like: |
77 |
> |
78 |
> PTUD=${PYTHON_COMPAT// /?,}? |
79 |
> |
80 |
|
81 |
The 'for impl in ${PYTHON_COMPAT}' loop is actually run in global |
82 |
scope later, to set *DEPEND on each python implementation; i haven't |
83 |
checked but it's possible it can be done there. Also, other bits are |
84 |
already using temp variables in global scope. Also2, since this var |
85 |
needs to be substituted directly into atoms of the ebuild's *DEPEND, |
86 |
imo it needs to be in global scope as well |
87 |
|
88 |
|
89 |
> But then you would have to 'clean up' PYTHON_COMPAT first to avoid |
90 |
> non-space whitespace and so on. |
91 |
> |
92 |
>> EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test |
93 |
>> [Snip!] |
94 |
>> |
95 |
>> case "${EAPI}" in |
96 |
> |
97 |
> Er, that thing should go after EAPI check. |
98 |
> |
99 |
|
100 |
|
101 |
Could be, yes. I had thought to set it before the check as |
102 |
PYTHON_COMPAT itself is assigned (if unset) before the check. |
103 |
- -----BEGIN PGP SIGNATURE----- |
104 |
Version: GnuPG v2.0.19 (GNU/Linux) |
105 |
|
106 |
iF4EAREIAAYFAlBJCTUACgkQ2ugaI38ACPD3TwEAj1rtDO1Rpbmf0g+nU+oHTj5Y |
107 |
HIFVsn+bzbx+CB1xU5QBAKxXx5p33y4dhk03zM1VjRWM5J9QdC/uDGq42yapnfdd |
108 |
=hm2B |
109 |
- -----END PGP SIGNATURE----- |
110 |
-----BEGIN PGP SIGNATURE----- |
111 |
Version: GnuPG v2.0.19 (GNU/Linux) |
112 |
|
113 |
iF4EAREIAAYFAlBJCrMACgkQ2ugaI38ACPAKsQD/VirFeTqL+ZdbGq0lgD8HuuyG |
114 |
0YrQGw0i8CYN5eMdtpIBAIszTewkBVF75lWGull7MmWYfZkyYRPUI/b6JNnUO/o6 |
115 |
=fQvj |
116 |
-----END PGP SIGNATURE----- |