FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-13-2011, 04:37 PM
Mike Frysinger
 
Default elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

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
 
Old 11-13-2011, 04:45 PM
Samuli Suominen
 
Default elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

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()
 
Old 11-13-2011, 04:58 PM
Nirbheek Chauhan
 
Default elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

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
 
Old 11-13-2011, 05:03 PM
Mike Frysinger
 
Default elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

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
 
Old 11-14-2011, 04:09 PM
Mike Frysinger
 
Default elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds

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
 

Thread Tools




All times are GMT. The time now is 06:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org