From: Mike Frysinger <vapier@gentoo.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 [thread overview]
Message-ID: <201111131237.50507.vapier@gentoo.org> (raw)
[-- 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 --]
next reply other threads:[~2011-11-13 17:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-13 17:37 Mike Frysinger [this message]
2011-11-13 17:45 ` [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds Samuli Suominen
2011-11-13 17:58 ` Nirbheek Chauhan
2011-11-13 18:03 ` Mike Frysinger
2011-11-14 17:09 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201111131237.50507.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox