public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races)
@ 2013-12-18 22:20 Greg Turner
  2013-12-18 23:32 ` Mike Frysinger
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Turner @ 2013-12-18 22:20 UTC (permalink / raw
  To: gentoo-portage-dev

On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger <vapier@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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* 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)
  2013-12-18 22:20 [gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races) Greg Turner
@ 2013-12-18 23:32 ` Mike Frysinger
  2013-12-19  2:36   ` Greg Turner
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Frysinger @ 2013-12-18 23:32 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Greg Turner

[-- Attachment #1: Type: Text/Plain, Size: 1595 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* 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)
  2013-12-18 23:32 ` Mike Frysinger
@ 2013-12-19  2:36   ` Greg Turner
  0 siblings, 0 replies; 3+ messages in thread
From: Greg Turner @ 2013-12-19  2:36 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Mike Frysinger

On Wed, Dec 18, 2013 at 3:32 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> 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.

Good point, hadn't even thought that far ahead...  In truth I'll
probably procrastinate and/or not bother until my queue of
half-realized Gentoo contributions can be shortened a bit -- I doubt
anybody will die of inelegance in the meanwhile :)

-gmt


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-12-19  2:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-18 22:20 [gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races) Greg Turner
2013-12-18 23:32 ` Mike Frysinger
2013-12-19  2:36   ` Greg Turner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox