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 1RPe0i-0004yB-Kw for garchives@archives.gentoo.org; Sun, 13 Nov 2011 17:38:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72A8021C0A3; Sun, 13 Nov 2011 17:38:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 9A2BF21C02C for ; Sun, 13 Nov 2011 17:37:51 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 094361B4008 for ; Sun, 13 Nov 2011 17:37:51 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds Date: Sun, 13 Nov 2011 12:37:49 -0500 User-Agent: KMail/1.13.7 (Linux/3.1.0; KDE/4.6.5; x86_64; ; ) 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 Content-Type: multipart/signed; boundary="nextPart1956742.bXoveVNdi2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201111131237.50507.vapier@gentoo.org> X-Archives-Salt: 8235525d-f725-481f-9a9c-ab7be7a41b01 X-Archives-Hash: 14cb41f817b48fcadfa81c470a7f936a --nextPart1956742.bXoveVNdi2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 itse= lf, 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 =2Dmike =2D-- autotools.eclass +++ autotools.eclass @@ -146,7 +146,7 @@ =20 # Call it here to prevent failures due to elibtoolize called _before_ # eautoreconf. We set $S because elibtoolize runs on that #265319 =2D S=3D${PWD} elibtoolize + S=3D${PWD} elibtoolize --force =20 return 0 } =2D-- libtool.eclass +++ libtool.eclass @@ -119,6 +119,7 @@ local do_uclibc=3D"yes" local deptoremove=3D local do_shallow=3D"no" + local force=3D"false" local elt_patches=3D"install-sh ltmain portage relink max_cmd_len sed tes= t tmp cross as-needed" =20 for x in "$@" ; do @@ -153,6 +154,9 @@ --no-uclibc) do_uclibc=3D"no" ;; + --force) + force=3D"true" + ;; *) eerror "Invalid elibtoolize option: ${x}" die "elibtoolize called with ${x} ??" @@ -186,9 +190,15 @@ for d in "$@" ; do export ELT_APPLIED_PATCHES=3D =20 =2D [[ -f ${d}/.elibtoolized ]] && continue + if [[ -f ${d}/.elibtoolized ]] ; then + ${force} || continue + fi =20 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 =20 for p in ${elt_patches} ; do local ret=3D0 --nextPart1956742.bXoveVNdi2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJOwABuAAoJEEFjO5/oN/WBZ0cP/3B6ws6GIube+bU7fRBWzQ4V c/mIndnGajWIJfi20wQ3ZkTDhAtt2kDbFtR+cVllQXba+z/cNXrGtIG+vMn3tPdj 6T5exwIgKHStvJCvKuews6qY4QWzTjKrgdxWnWelQu2OLyLmdf7Dn9BKLXueAaGn hRF0wLpEQx2NRon8r8FhrmQ0+cA/zYS6I0VImsOPozZ+sZbTos8bVt6uqIc+vMGu wKMFLbMd5Lr1wkS6fMQsLvl96XO3wAXa5tAf532sZ/ehrhHGPJoSlFky6UxNekHf 2CzPN/mdRL+HE2Ylopr1GtDLah2tn3JdxjujXGXLbeWlM9wUYyKLhJQL6G+/nJYn dkdML8ovR1RGwTbEvl4XtzVO1Kjx7pDT57DMFshponfWmpY8yHUuk9amFn6zC4xu EVgb96ioBBKnIw1LRKWkodY39MbE2pqbB2kDisXDtW8At+k396dLGWS7WZy+xflX CenYnONfvylQ6qN3P5qh43oB4Um4boYAerJ+YhE9m7EBTz/2qM+BLdBJY7SaoDul xsOYsgo85jW3USvDioZ14vYV4p0d7O/JKZh/f9PiwfcxNdXyQaBwgYva1bDaFhfb aDDDPqholEeffVbeuMAOFXiQDYeOzQI7b3fWDKMvS1gJC+blULtxkK1yNAn9812R TNTPK7B7SAPRtuP7k7Rl =TToU -----END PGP SIGNATURE----- --nextPart1956742.bXoveVNdi2--