From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RPe9g-0006Vj-4K for garchives@archives.gentoo.org; Sun, 13 Nov 2011 17:47:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B3C421C1AA; Sun, 13 Nov 2011 17:47:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D992521C057 for ; Sun, 13 Nov 2011 17:47:10 +0000 (UTC) Received: from [192.168.168.169] (dyn-199-173-dsl.vsp.fi [83.146.199.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id BBB5A1B4008 for ; Sun, 13 Nov 2011 17:47:09 +0000 (UTC) Message-ID: <4EC0024E.2030208@gentoo.org> Date: Sun, 13 Nov 2011 19:45:50 +0200 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111111 Thunderbird/8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds References: <201111131237.50507.vapier@gentoo.org> In-Reply-To: <201111131237.50507.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 6aaf7098-2fac-434b-85eb-11c37619c3f1 X-Archives-Hash: cd06adef210b5809df95900ca07ff4f9 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()