1 |
On Thu, May 2, 2013 at 5:26 AM, Michał Górny <mgorny@g.o> wrote: |
2 |
> Hi, |
3 |
> |
4 |
> I've thought for a bit and got the conclusion that the best solution |
5 |
> for quite an irritating syntax of autotools-multilib is to use |
6 |
> sub-phase functions. |
7 |
|
8 |
Sorry for the delayed response, but having been playing with this |
9 |
stuff lately, and I'd like to state for the record that I |
10 |
whole-heartedly endorse this product and/or service. |
11 |
|
12 |
> autotools_configure() |
13 |
> autotools_install() |
14 |
> autotools_install_all() |
15 |
|
16 |
I like that you manage to avoid syntax like: |
17 |
|
18 |
autotools_multilib_${phase}_${applicability-specifier}_${etc}... |
19 |
|
20 |
:) |
21 |
|
22 |
The name of the game is to get from where we are now, to where we want |
23 |
to be (presumably, a future in which we can rm -rf |
24 |
${PORTDIR}/app-emulation/emul-linux-x86-*), with a minimum of |
25 |
repetitive and/or difficult retrofit labor. |
26 |
|
27 |
Ideally, to multilib-retrofit an ebuild, the ebuild-repair-person |
28 |
would just chop up the code a bit, and indicate to the framework which |
29 |
snippets pertain to which ABI's or are ABI-independent. |
30 |
|
31 |
We're nowhere near that now. As you suggest, the problem is that |
32 |
there's no way to "hook" any per-ABI script code into the |
33 |
autotools-multilib phase functions without copy pasting the whole |
34 |
boilerplate, which shrinks the value-proposition of autotools-multilib |
35 |
(vs. direct inheritance to multilib-build) down to almost nothing. |
36 |
|
37 |
All but the most simple pre-USE_EXPAND-abi-ebuilds have snippets of |
38 |
script code that want to run on a per-ABI basis, often inconveniently |
39 |
interspersed between src_prepare() and src_configure(), and there is |
40 |
no low-effort way to wedge that code into the autotools-multilib |
41 |
framework as implemented. |
42 |
|
43 |
Often, there is some clever substitution that can be made to bridge |
44 |
this feature-gap -- but by now the ebuild-repair-person is well into |
45 |
"investigating/thinking deeply/drawing-board" mode, precisely where he |
46 |
doesn't want to find himself if he's trying to quickly blow through a |
47 |
deeply-entangled batch of 50 or 100 ebuilds requiring simultaneous |
48 |
retrofitting. |
49 |
|
50 |
> While this seems rather cosmetic... |
51 |
|
52 |
It's not just a cosmetic problem. ... but, a brief diversion about |
53 |
aesthetics: I think, in ebuild-writing, there's a fine line between |
54 |
cosmetically fucked and just plain fucked. Likewise, the converse |
55 |
also holds: an aesthetically blessed ebuild is probably blessed for |
56 |
developers, bugzilla worker-bees, and end-users (gentoo sysadmins) |
57 |
alike. |
58 |
|
59 |
So, in short, cosmetic improvements are good and intrinsically |
60 |
important. Furthermore, the term "cosmetic" has connotations of |
61 |
"ineffectual": that is not the case here, there are real practical |
62 |
problems being solved -- your proposal ENABLES the |
63 |
ebuild-repair-person to shuffle around code in a seemingly trivial |
64 |
manner, but that's NOT an option with the current implementation, |
65 |
instead the ebuild-repair-person must struggle against the limitations |
66 |
of the framework (in addition to figuring out whatever true semantic |
67 |
change is required by the retrofit). |
68 |
|
69 |
Anyhow, meanwhile, back on planet Earth... |
70 |
|
71 |
> The sub-phases without '_all' suffix are run inside BUILD_DIR, and |
72 |
> repeated for each multilib ABI. The sub-phases with '_all' are always |
73 |
> run only once, and inside S. |
74 |
|
75 |
It's clearly a move in the right direction. New choke points would |
76 |
probably reveal themselves once we were freed from the tyranny of |
77 |
constantly typing in the same code over and over :) |
78 |
|
79 |
I do think "all" vs. "" is dsylexia-inducing and should be changed... perhaps: |
80 |
|
81 |
at_${phase}_abi: per-abi steps (i.e., probably in per-abi ${BUILD_DIR}) |
82 |
at_${phase}: global steps (i.e., in ${S}) |
83 |
|
84 |
s/at/autotools/ obv.... or just leave it! short==good here. |
85 |
|
86 |
Anyhow, those really are trivial semantic matters. |
87 |
|
88 |
I also think your proposal could go a bit further in the ability to |
89 |
slice-and-dice the sub-phase functions. For example, there might be |
90 |
uses for granularity like: |
91 |
|
92 |
at_${phase}: as before |
93 |
|
94 |
at_${phase}_all: as before |
95 |
|
96 |
at_${phase}_${ABI}: single-abi-specific stuff executed before |
97 |
at_${phase}, i.e., platform-specific configure tweaks |
98 |
|
99 |
at_${phase}_best: stuff that needs to happen in ${BUILD_DIR}, but |
100 |
should only happen for DEFAULT_ABI, i.e.:, compile documentation from |
101 |
source, full emake installs to deploy unwrapped header files and |
102 |
/usr/share/doc stuff, etc. |
103 |
|
104 |
Cross-compile support might suggest a couple of additional sub-phases |
105 |
(i.e.: a sub-phase to generate ${CBUILD}-targeted intermediate tools |
106 |
(perhaps only during cross-compiles, but I really wish somehow that |
107 |
could be coded just once, tagged, and the framework could decide |
108 |
whether to do anything unusual with it based on context. |
109 |
|
110 |
> What are your thoughts? The patch is sent in reply to this mail. |
111 |
|
112 |
Just saw your message that you are abandoning this proposal due to |
113 |
lack of interest. I think the lack of comments is not particularly |
114 |
surprising. How many people are actively getting their hands dirty |
115 |
attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib? |
116 |
I'd wager you're the only one, unless you want to count me over the |
117 |
last 24 hours or so but I'm just dabbling and will probably lose |
118 |
interest. |
119 |
|
120 |
In other words, probably you are the only person in a position to see |
121 |
what the requirements are. If you are concerned about building stuff |
122 |
with no "eyeballs" / feedback, then put them in new eclasses instead |
123 |
of fixing the old ones (it's 'prolly better for back-compatibility to |
124 |
do so anyhow). But I'm 100% convinced you're on the right track |
125 |
because I was about to start building what you described myself (and |
126 |
I'm /never/ wrong! hahaha, ok, far from it, but as they say, "even if |
127 |
I do say so myself...") |
128 |
|
129 |
-gmt |