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()
