[gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]

it seems we have some cases where eclasses/ebuilds interact poorly.  for
example, if an eclass runs eautoreconf or elibtoolize, and then the ebuild
does some stuff where it ends up running eautoreconf, subsequent elibtoolize
calls are skipped.

this means that the work done by the earlier elibtoolize call was all for
naught, as eautoreconf blows all of its work away be regenerating the files
elibtoolize patched.  and when eautoreconf attempts to run elibtoolize itself,
we don't get all the fun patches since elibtoolize detected it was run
already.

rather than have this continue to silently ignore the issue, i'm thinking of
making these changes:
	- elibtoolize now has a --force flag
	- eautoreconf always calls elibtoolize with --force
	- if elibtoolize detects a previous run with --force, it warns, but runs
this way we complain, but at least we continue to work

the prefix guys first brought this up here:
	https://bugs.gentoo.org/232820
but i've hit this since with cross-compiling Linux targets:
	- pygobject ebuild inherits gnome2 eclass
	- pygobject's src_prepare first calls gnome2_src_prepare
	- gnome2_src_prepare always calls elibtoolize (which normally is good)
	- pygobject's src_prepare applies patches and then calls eautoreconf
	- eautoreconf regens all files that where patched earlier
	- eautoreconf's call to elibtoolize is skipped
	- builds fail which need those elibtoolize patches
-mike

--- autotools.eclass
+++ autotools.eclass
@@ -146,7 +146,7 @@
 
 	# Call it here to prevent failures due to elibtoolize called _before_
 	# eautoreconf.  We set $S because elibtoolize runs on that #265319
-	S=${PWD} elibtoolize
+	S=${PWD} elibtoolize --force
 
 	return 0
 }
--- libtool.eclass
+++ libtool.eclass
@@ -119,6 +119,7 @@
 	local do_uclibc="yes"
 	local deptoremove=
 	local do_shallow="no"
+	local force="false"
 	local elt_patches="install-sh ltmain portage relink max_cmd_len sed test tmp cross as-needed"
 
 	for x in "$@" ; do
@@ -153,6 +154,9 @@
 			--no-uclibc)
 				do_uclibc="no"
 				;;
+			--force)
+				force="true"
+				;;
 			*)
 				eerror "Invalid elibtoolize option: ${x}"
 				die "elibtoolize called with ${x} ??"
@@ -186,9 +190,15 @@
 	for d in "$@" ; do
 		export ELT_APPLIED_PATCHES=
 
-		[[ -f ${d}/.elibtoolized ]] && continue
+		if [[ -f ${d}/.elibtoolized ]] ; then
+			${force} || continue
+		fi
 
 		einfo "Running elibtoolize in: ${d#${WORKDIR}/}/"
+		if [[ -f ${d}/.elibtoolized ]] ; then
+			ewarn "  We've already been run in this tree; you should"
+			ewarn "  avoid this if possible (perhaps by filing a bug)"
+		fi
 
 		for p in ${elt_patches} ; do
 			local ret=0

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

Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[Samuli Suominen]

On 11/13/2011 07:37 PM, Mike Frysinger wrote:
> it seems we have some cases where eclasses/ebuilds interact poorly.  for
> example, if an eclass runs eautoreconf or elibtoolize, and then the ebuild
> does some stuff where it ends up running eautoreconf, subsequent elibtoolize
> calls are skipped.
> 
> this means that the work done by the earlier elibtoolize call was all for
> naught, as eautoreconf blows all of its work away be regenerating the files
> elibtoolize patched.  and when eautoreconf attempts to run elibtoolize itself,
> we don't get all the fun patches since elibtoolize detected it was run
> already.
> 
> rather than have this continue to silently ignore the issue, i'm thinking of
> making these changes:
> 	- elibtoolize now has a --force flag
> 	- eautoreconf always calls elibtoolize with --force
> 	- if elibtoolize detects a previous run with --force, it warns, but runs
> this way we complain, but at least we continue to work
> 
> the prefix guys first brought this up here:
> 	https://bugs.gentoo.org/232820
> but i've hit this since with cross-compiling Linux targets:
> 	- pygobject ebuild inherits gnome2 eclass
> 	- pygobject's src_prepare first calls gnome2_src_prepare
> 	- gnome2_src_prepare always calls elibtoolize (which normally is good)
> 	- pygobject's src_prepare applies patches and then calls eautoreconf
> 	- eautoreconf regens all files that where patched earlier
> 	- eautoreconf's call to elibtoolize is skipped
> 	- builds fail which need those elibtoolize patches
> -mike

also a bug in those ebuilds then, since gnome2_src_prepare() should
always be the last call/command in src_prepare()

Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[Nirbheek Chauhan]

On Sun, Nov 13, 2011 at 11:15 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> also a bug in those ebuilds then, since gnome2_src_prepare() should
> always be the last call/command in src_prepare()
>

It's slightly complicated. We don't always want gnome2_src_prepare to
be the last call in src_prepare for live ebuilds, and ebuilds where we
sed configure or Makefile.in directly to avoid an eautoreconf (it's
extremely slow on arm/mips etc).

It's very easy to not do the right thing. I think mike's change is a good thing.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[Mike Frysinger]

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

On Sunday 13 November 2011 12:45:50 Samuli Suominen wrote:
> On 11/13/2011 07:37 PM, Mike Frysinger wrote:
> > but i've hit this since with cross-compiling Linux targets:
> > 	- pygobject ebuild inherits gnome2 eclass
> > 	- pygobject's src_prepare first calls gnome2_src_prepare
> > 	- gnome2_src_prepare always calls elibtoolize (which normally is good)
> > 	- pygobject's src_prepare applies patches and then calls eautoreconf
> > 	- eautoreconf regens all files that where patched earlier
> > 	- eautoreconf's call to elibtoolize is skipped
> > 	- builds fail which need those elibtoolize patches
> 
> also a bug in those ebuilds then, since gnome2_src_prepare() should
> always be the last call/command in src_prepare()

yes, but the current state is that people don't notice and things silently 
break.  i'm turning the situation into a QA warning so bug reports get 
filed/fixed, and things continue to work in the mean time.
-mike

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

Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

[Mike Frysinger]

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

http://sources.gentoo.org/eclass/autotools.eclass?r1=1.109&r2=1.110
http://sources.gentoo.org/eclass/libtool.eclass?r1=1.94&r2=1.95
-mike

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