[gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races)
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
URL: https://bugs.gentoo.org/487478
Perhaps, with this bug resolved, this matter falls under the more
trouble than its worth to fix category -- but...
My hunch is that the decision to put the config.{sub,guess}
replacement code in econf was intended as a quick-and-dirty way to
avoid doing the replacements, in cases where no configure script runs
in an ebuild.
Post EAPI-2, the convention that hacking on the sources in ${S} is
a no-no after src_prepare has clearly crystallized considerably (I'm
guessing the code has EAPI-[01] origins); violating that convention in
econf seems awkward.
Further, the approach has a few other non-fantastic qualities:
o It doesn't run, if, for some reason, the ebuild must invoke
configure directly rather than use econf
o when econf is invoked repeatedly, it does the same
O(# of dirs in ${S}) noop over and over
In short... moving the config.{sub,guess} replacement code (but
probably not the shebang patching for reasons of expedience) to some
post-src_prepare place would probably be more elegant and pretty easy
to do.
As for the only replace if we econf issue, I can't imagine that
simply doing the replacement unconditionally would be so bad (perhaps,
with a hard-coded gnuconfig exemption, if that's needed).
Anyhow, it's very much not a big deal. #487478 (which was entirely
theoretical, to begin with) is fixed, and there are way bigger fish to
fry in Gentoo-land... just thought I'd mention it, though, mostly as
an open note-to-self, I guess.
-gmt
Re: [gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races)
On Wednesday 18 December 2013 17:20:32 Greg Turner wrote:
My hunch is that the decision to put the config.{sub,guess}
replacement code in econf was intended as a quick-and-dirty way to
avoid doing the replacements, in cases where no configure script runs
in an ebuild.
it was intended as the easy answer so that all packages would get it for
free. previously, we had an eclass, and had to update every single package
to call a function in that eclass. it sucked hard. it makes sense to have it
in `econf` because that func is only used in conjunction with autotool based
packages.
Post EAPI-2, the convention that hacking on the sources in ${S} is
a no-no after src_prepare has clearly crystallized considerably (I'm
guessing the code has EAPI-[01] origins); violating that convention in
econf seems awkward.
this code existed long before EAPI was ever a thing
o It doesn't run, if, for some reason, the ebuild must invoke
configure directly rather than use econf
this happens in like 3 packages. we can suck it up.
o when econf is invoked repeatedly, it does the same
O(# of dirs in ${S}) noop over and over
true, but it hasn't been a big enough deal for us to care
In short... moving the config.{sub,guess} replacement code (but
probably not the shebang patching for reasons of expedience) to some
post-src_prepare place would probably be more elegant and pretty easy
to do.
that discussion should happen on gentoo-dev in conjunction with PMS. or file a
bug if there isn't one already.
-mike
signature.asc
Description: This is a digitally signed message part.
