1 |
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger <vapier@g.o> wrote: |
2 |
> URL: https://bugs.gentoo.org/487478 |
3 |
|
4 |
Perhaps, with this bug resolved, this matter falls under the "more |
5 |
trouble than its worth to fix" category -- but... |
6 |
|
7 |
My hunch is that the decision to put the config.{sub,guess} |
8 |
replacement code in econf was intended as a quick-and-dirty way to |
9 |
avoid doing the replacements, in cases where no configure script runs |
10 |
in an ebuild. |
11 |
|
12 |
Post EAPI-2, the convention that hacking on the sources in "${S}" is |
13 |
a "no-no" after src_prepare has clearly crystallized considerably (I'm |
14 |
guessing the code has EAPI-[01] origins); violating that convention in |
15 |
econf seems awkward. |
16 |
|
17 |
Further, the approach has a few other non-fantastic qualities: |
18 |
|
19 |
o It doesn't run, if, for some reason, the ebuild must invoke |
20 |
configure directly rather than use econf |
21 |
|
22 |
o when econf is invoked repeatedly, it does the same |
23 |
O(# of dirs in ${S}) noop over and over |
24 |
|
25 |
In short... moving the config.{sub,guess} replacement code (but |
26 |
probably not the shebang patching for reasons of expedience) to some |
27 |
post-src_prepare place would probably be more elegant and pretty easy |
28 |
to do. |
29 |
|
30 |
As for the "only replace if we econf" issue, I can't imagine that |
31 |
simply doing the replacement unconditionally would be so bad (perhaps, |
32 |
with a hard-coded gnuconfig exemption, if that's needed). |
33 |
|
34 |
Anyhow, it's very much not a big deal. #487478 (which was entirely |
35 |
theoretical, to begin with) is fixed, and there are way bigger fish to |
36 |
fry in Gentoo-land... just thought I'd mention it, though, mostly as |
37 |
an open note-to-self, I guess. |
38 |
|
39 |
-gmt |