Package: automake;
Reported by: Peter Rosin <peda <at> lysator.liu.se>
Date: Thu, 20 Oct 2011 12:45:02 UTC
Severity: normal
Tags: patch
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9807 in the body.
You can then email your comments to 9807 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Thu, 20 Oct 2011 12:45:03 GMT) Full text and rfc822 format available.Peter Rosin <peda <at> lysator.liu.se>
:bug-automake <at> gnu.org
.
(Thu, 20 Oct 2011 12:45:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Peter Rosin <peda <at> lysator.liu.se> To: bug-automake <at> gnu.org Subject: libtool is not found by the automake testsuite Date: Thu, 20 Oct 2011 14:42:53 +0200
Hi! When I do a simple ./configure, make, make check, Automake will not run tests related to Libtool, because there is no Libtool installed in the prefix this Automake is destined for (i.e. /usr/local/). Is it really expected that users should have to install Libtool in the prefix before the Automake testsuite will run the Libtool tests? From looking at the code, I suspect gettext is also suffering. I do understand that there is a desire to keep undesired macros out of the way, but the price seems a bit high... Cheers, Peter
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Thu, 20 Oct 2011 13:22:02 GMT) Full text and rfc822 format available.Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: bug-automake <at> gnu.org Cc: Peter Rosin <peda <at> lysator.liu.se>, 9807 <at> debbugs.gnu.org Subject: Re: bug#9807: libtool is not found by the automake testsuite Date: Thu, 20 Oct 2011 15:19:47 +0200
On Thursday 20 October 2011, Peter Rosin wrote: > Hi! > Hi Peter, thanks for the report. > When I do a simple ./configure, make, make check, Automake will > not run tests related to Libtool, because there is no Libtool > installed in the prefix this Automake is destined for (i.e. > /usr/local/). > > Is it really expected that users should have to install Libtool > in the prefix before the Automake testsuite will run the Libtool > tests? > > From looking at the code, I suspect gettext is also suffering. > And it gets worse: as another unwanted side effect, "make distcheck" won't run the libtool and gettext tests, ever. Not pretty. > I do understand that there is a desire to keep undesired macros > out of the way, but the price seems a bit high... > I agree, and improving the situation is on my TODO list for the testsuite-work branch. Here is the planned roadmap: 1. Add a new `libtool-macros' requirement, for tests that don't need libool/libtoolize, but only the libtool-provided autoconf macros. Adjust `$required' of the involved tests accordingly. 2. Make the `libtool-macros' and `gettext' requirements not trigger any search for `libtool.m4' and `gettext.m4' files, but rather rely on the ACLOCAL_PATH variable (this introduces possibility of spurious failures, that we'll fix in a later step). 3. Look for the libtool/gettext macros at configure time. The default location will still be the the prefix this Automake is destined for; but then we should also: - take a look at /usr/local and /usr uncondionally (useful e.g. if someone is installing automake in his home directory, which is hardly a good reason to skip the libtool and gettext tests); - honour the recently-introduced ACLOCAL_PATH (and continue to honour the `dirlist' file in acdir, if any); - offer configure option(s) to override the automatic checks (the user is always right!). These points might be implemented in seprate steps, of course. 4. In tests requiring `libtool-macros' and `gettext', extend the ACLOCAL_PATH variable appropriately. This should fix any regreession introduced by the step (2). This is the "tentative" roadmap. As usual, suggestions are weclome -- as well as patches ;-) Regards, Stefano
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Thu, 20 Oct 2011 13:22:02 GMT) Full text and rfc822 format available.bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Sun, 06 Nov 2011 15:58:01 GMT) Full text and rfc822 format available.Message #14 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: Jim Meyering <jim <at> meyering.net> Cc: 9807 <at> debbugs.gnu.org, automake-patches <at> gnu.org Subject: custom libtool installation and automake testsuite failures (was: Re: [PATCH] tests: avoid false positive due to change in --help formatting) Date: Sun, 6 Nov 2011 16:54:53 +0100
Hi Jim. On Sunday 06 November 2011, Jim Meyering wrote: > Stefano Lattarini wrote: > > On Friday 04 November 2011, Stefano Lattarini wrote: > >> On Friday 04 November 2011, Stefano Lattarini wrote: > >> > > >> > [SNIP] > >> > > >> > Attached is a patch in this spirit; I'll push in a few hours if there is > >> > no objection. > >> > > > Pushed now. > > Thanks. > > With that, I would have had no test failures on master, but now I > have 20+. The cause is that in the mean time I've installed a private > copy of libtool-2.4.2, while parts of the test seem to expect the > version installed as /usr/bin/libtool: 2.4: > > libtool: Version mismatch error. This is libtool 2.4.2, but the > libtool: definition of this LT_INIT comes from libtool 2.4. > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 > libtool: and run autoconf again. > make: *** [libd.lo] Error 63 > Hmmm... my guess is that the automake testsuite is finding and using the system-wide versions of the libtool macros, instead of the ones of your custom libtool installation; see also automake bug#9807: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9807> (which I'm CC'ing, for reference). This sucks, and will hopefully be fixed in the first automake release after 1.11.2 (either 1.12 or 1.11.3). Just to verify this hunch of mine is correct, can you tell me how you've configured automake, where you have installed your private libtool version, and post the logs of the failing test(s)? > Should I expect those tests to pass in this case? > For the moment, I *think* (hope?) that you can work around the problem as follows: $ cd ~/src/automake # Directory of your automake checkout. $ mkdir _inst $ ./configure --prefix=`pwd`/_inst $ make install $ cat > _inst/share/aclocal/dirlist <<END # Directory of your libtool macros from your custom libtool # installation. /opt/libtool-2.4.2/share/aclocal # Directory of your system-wide third-party aclocal macros. /usr/share/aclocal END Let me know how this works out. Thanks, Stefano
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Sun, 06 Nov 2011 16:15:02 GMT) Full text and rfc822 format available.Message #17 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Jim Meyering <jim <at> meyering.net> To: Stefano Lattarini <stefano.lattarini <at> gmail.com> Cc: 9807 <at> debbugs.gnu.org, automake-patches <at> gnu.org Subject: Re: custom libtool installation and automake testsuite failures Date: Sun, 06 Nov 2011 17:11:37 +0100
Stefano Lattarini wrote: ... > Just to verify this hunch of mine is correct, can you tell me how > you've configured automake, where you have installed your private > libtool version, and post the logs of the failing test(s)? > >> Should I expect those tests to pass in this case? >> > For the moment, I *think* (hope?) that you can work around the > problem as follows: > > $ cd ~/src/automake # Directory of your automake checkout. > $ mkdir _inst > $ ./configure --prefix=`pwd`/_inst > $ make install > $ cat > _inst/share/aclocal/dirlist <<END > # Directory of your libtool macros from your custom libtool > # installation. > /opt/libtool-2.4.2/share/aclocal > # Directory of your system-wide third-party aclocal macros. > /usr/share/aclocal > END > > Let me know how this works out. Thanks for the hint. I install my own versions of m4, autoconf, automake, libtool, etc., using --prefix=/p, and I put /p/bin earlier in PATH than /usr/bin, etc. Because of that, I've always had to initialize /p/share/aclocal/dirlist to contain /usr/share/aclocal. Until today, I did it like this, so that uses of macros not installed in my private hierarchy would still be found: mkdir --verbose -p $(aclocal --print-ac-dir) echo /usr/share/aclocal >> $(aclocal --print-ac-dir)/dirlist Now I see that I must explicitly list /p/share/aclocal, too, presumably before any other directory name, so I've done this: mkdir --verbose -p $(aclocal --print-ac-dir) printf '%s/share/aclocal\n' /p /usr >> $(aclocal --print-ac-dir)/dirlist With that, all of the tests on automake.master pass once again. Thanks!
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Sun, 06 Nov 2011 16:46:02 GMT) Full text and rfc822 format available.Message #20 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: Jim Meyering <jim <at> meyering.net> Cc: 9807 <at> debbugs.gnu.org, automake-patches <at> gnu.org Subject: Re: custom libtool installation and automake testsuite failures Date: Sun, 6 Nov 2011 17:42:59 +0100
On Sunday 06 November 2011, Jim Meyering wrote: > I install my own versions of m4, autoconf, automake, libtool, etc., > using --prefix=/p, and I put /p/bin earlier in PATH than /usr/bin, etc. > > Because of that, I've always had to initialize > /p/share/aclocal/dirlist to contain /usr/share/aclocal. > Until today, I did it like this, so that uses of macros not > installed in my private hierarchy would still be found: > > mkdir --verbose -p $(aclocal --print-ac-dir) > echo /usr/share/aclocal >> $(aclocal --print-ac-dir)/dirlist > > Now I see that I must explicitly list /p/share/aclocal, too, > presumably before any other directory name, > That's weird; if I'm not mistaken, m4 files from ${acdir} should take precedence over those from directories listed in ${acdir}/dirlist ... > so I've done this: > > mkdir --verbose -p $(aclocal --print-ac-dir) > printf '%s/share/aclocal\n' /p /usr >> $(aclocal --print-ac-dir)/dirlist > I don't understand why this should be needed ... > With that, all of the tests on automake.master pass once again. > ... and I'm baffled by the fact it indeed works. Could you please try running a libtool-requiring test passing `--verbose' to the aclocal invocation there, to see what happens? Thanks, Stefano
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Sun, 06 Nov 2011 16:58:01 GMT) Full text and rfc822 format available.Message #23 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Jim Meyering <jim <at> meyering.net> To: Stefano Lattarini <stefano.lattarini <at> gmail.com> Cc: 9807 <at> debbugs.gnu.org, automake-patches <at> gnu.org Subject: Re: custom libtool installation and automake testsuite failures Date: Sun, 06 Nov 2011 17:54:32 +0100
[Message part 1 (text/plain, inline)]
Stefano Lattarini wrote: > On Sunday 06 November 2011, Jim Meyering wrote: >> I install my own versions of m4, autoconf, automake, libtool, etc., >> using --prefix=/p, and I put /p/bin earlier in PATH than /usr/bin, etc. >> >> Because of that, I've always had to initialize >> /p/share/aclocal/dirlist to contain /usr/share/aclocal. >> Until today, I did it like this, so that uses of macros not >> installed in my private hierarchy would still be found: >> >> mkdir --verbose -p $(aclocal --print-ac-dir) >> echo /usr/share/aclocal >> $(aclocal --print-ac-dir)/dirlist >> >> Now I see that I must explicitly list /p/share/aclocal, too, >> presumably before any other directory name, >> > That's weird; if I'm not mistaken, m4 files from ${acdir} should take > precedence over those from directories listed in ${acdir}/dirlist ... > >> so I've done this: >> >> mkdir --verbose -p $(aclocal --print-ac-dir) >> printf '%s/share/aclocal\n' /p /usr >> $(aclocal --print-ac-dir)/dirlist >> > I don't understand why this should be needed ... > >> With that, all of the tests on automake.master pass once again. >> > ... and I'm baffled by the fact it indeed works. > > Could you please try running a libtool-requiring test passing `--verbose' > to the aclocal invocation there, to see what happens? For the record, with /p/bin early in my path and self-built/installed autoconf, automake, libtool-2.4.2 (with prefix=/p), with this, all automake tests pass: $ cat /p/share/aclocal/dirlist /p/share/aclocal /usr/share/aclocal If I change that to omit /p/share/aclocal, $ cat /p/share/aclocal/dirlist /usr/share/aclocal Then 29 automake tests fail:
[test-suite.log.xz (application/octet-stream, attachment)]
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Wed, 14 Dec 2011 13:11:01 GMT) Full text and rfc822 format available.Message #26 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: automake-patches <at> gnu.org Cc: 9807 <at> debbugs.gnu.org Subject: [PATCH] {maint} tests: better handling of gettext and libtool requirements Date: Wed, 14 Dec 2011 14:06:15 +0100
This change fixes automake bug#9807. Before this change, the automake testsuite only looked for the `.m4' files containing libtool and gettext macros definitions in the directory `${prefix}/share/aclocal' (and in the directories specified by the `dirlist' file in there, if any), where ${prefix} was the configure-time automake installation prefix (defaulting to `/usr/local'). This approach had various shortcomings and disadvantages. Let's briefly describe the three major ones. First, on most GNU/Linux systems, a libtool or gettext installed from distro-provided packages (e.g., by dpkg on Debian/Ubuntu, or by rmp on RedHat/Fedora) would have `/usr', not `/usr/local', as its ${prefix}; so, trying to run the automake testsuite with a simple "./configure && make && make check" would have failed to execute the libtool and gettext tests on most GNU/Linux distros. It's true that it was quite easy to work around this issue, by creating a proper `/usr/local/share/aclocal/dirlist' file with an entry pointing to `/usr/share/aclocal' (a workaround in fact used by most automake developers); but the typical user wasn't aware of the necessity of this trick, so the libtool and gettext tests was usually skipped on testsuite runs "in the wild", thus needlessly reducing coverage. Second, the older testsuite behaviour made more difficult for the developers to run the testsuite with non-default libtool or gettext. For example, assume the developer is working on a system that has a default libtool version 1.5 installed in the /usr/local hierarchy; to improve coverage, the developer installs also a more modern libtool version, say 2.4, in its home directory, let's say in ~/libtool-2.4; he then tries to run the automake testsuite with this more modern libtool by doing an (apparently) simple: $ PATH=$HOME/libtool-2.4:$PATH make check But the automake testsuite would still look for libtool macros in /usr/local/share/aclocal, not in ~/libtool-2.4/share/aclocal, so the wrong version of the macros would be picked up, and the tests would either fail spuriously or (which would be worse) pass without truly covering the libtool version the developers was thinking to be testing with. Worse again, the automake testsuite would *unconditionally* look for libtool macros in /usr/local/share/aclocal, so even something like: $ export ACLOCAL_PATH=$HOME/libtool-2.4/share/aclocal $ PATH=$HOME/libtool-2.4:$PATH make check wouldn't work. Third and last, during a "make distcheck", automake is configured with a ${prefix} pointing to a proper subdirectory of the build directory (usually `pwd`/_inst), which gets created on-the-fly; in this case, with the old approach, the automake testsuite never found the libtool and gettext macro files, ans so the libtool and gettext tests was *always* skipped in a "make distcheck". * tests/libtool-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/gettext-macros.test: New helper test, looking (with the help of the `libtoolize' script) for libtool macro files required by most libtool tests, and making them easily accessible. * tests/defs.in: Update to make it rely on the results and setups of `libtool-macros.test' and `gettext-macros.test'. * tests/Makefile.am: Declare dependency of all the logs of libtool tests from `libtool-macros.log', and all the logs of gettext tests from `gettext-macros.log'. --- ChangeLog | 71 +++++++++++++++++++++++++++++++++++++++ tests/Makefile.am | 62 ++++++++++++++++++++++++++++++++++ tests/Makefile.in | 62 ++++++++++++++++++++++++++++++++++ tests/defs.in | 43 +----------------------- tests/gettext-macros.test | 80 +++++++++++++++++++++++++++++++++++++++++++++ tests/libtool-macros.test | 62 ++++++++++++++++++++++++++++++++++ 6 files changed, 339 insertions(+), 41 deletions(-) create mode 100755 tests/gettext-macros.test create mode 100755 tests/libtool-macros.test diff --git a/ChangeLog b/ChangeLog index 826a4f7..6527e31 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,74 @@ +2011-12-14 Stefano Lattarini <stefano.lattarini <at> gmail.com> + + tests: better handling of gettext and libtool requirements + + This change fixes automake bug#9807. + + Before this change, the automake testsuite only looked for the + `.m4' files containing libtool and gettext macros definitions in + the directory `${prefix}/share/aclocal' (and in the directories + specified by the `dirlist' file in there, if any), where ${prefix} + was the configure-time automake installation prefix (defaulting + to `/usr/local'). + + This approach had various shortcomings and disadvantages. Let's + briefly describe the three major ones. + + First, on most GNU/Linux systems, a libtool or gettext installed + from distro-provided packages (e.g., by dpkg on Debian/Ubuntu, or + by rmp on RedHat/Fedora) would have `/usr', not `/usr/local', as + its ${prefix}; so, trying to run the automake testsuite with a + simple "./configure && make && make check" would have failed to + execute the libtool and gettext tests on most GNU/Linux distros. + It's true that it was quite easy to work around this issue, by + creating a proper `/usr/local/share/aclocal/dirlist' file with + an entry pointing to `/usr/share/aclocal' (a workaround in fact + used by most automake developers); but the typical user wasn't + aware of the necessity of this trick, so the libtool and gettext + tests was usually skipped on testsuite runs "in the wild", thus + needlessly reducing coverage. + + Second, the older testsuite behaviour made more difficult for + the developers to run the testsuite with non-default libtool or + gettext. For example, assume the developer is working on a system + that has a default libtool version 1.5 installed in the /usr/local + hierarchy; to improve coverage, the developer installs also a more + modern libtool version, say 2.4, in its home directory, let's say + in ~/libtool-2.4; he then tries to run the automake testsuite with + this more modern libtool by doing an (apparently) simple: + $ PATH=$HOME/libtool-2.4:$PATH make check + But the automake testsuite would still look for libtool macros in + /usr/local/share/aclocal, not in ~/libtool-2.4/share/aclocal, so + the wrong version of the macros would be picked up, and the tests + would either fail spuriously or (which would be worse) pass without + truly covering the libtool version the developers was thinking to + be testing with. + Worse again, the automake testsuite would *unconditionally* look + for libtool macros in /usr/local/share/aclocal, so even something + like: + $ export ACLOCAL_PATH=$HOME/libtool-2.4/share/aclocal + $ PATH=$HOME/libtool-2.4:$PATH make check + wouldn't work. + + Third and last, during a "make distcheck", automake is configured + with a ${prefix} pointing to a proper subdirectory of the build + directory (usually `pwd`/_inst), which gets created on-the-fly; + in this case, with the old approach, the automake testsuite never + found the libtool and gettext macro files, ans so the libtool and + gettext tests was *always* skipped in a "make distcheck". + + * tests/libtool-macros.test: New helper test, looking (with the + help of the `libtoolize' script) for libtool macro files required + by most libtool tests, and making them easily accessible. + * tests/gettext-macros.test: New helper test, looking (with the + help of the `libtoolize' script) for libtool macro files required + by most libtool tests, and making them easily accessible. + * tests/defs.in: Update to make it rely on the results and setups + of `libtool-macros.test' and `gettext-macros.test'. + * tests/Makefile.am: Declare dependency of all the logs of libtool + tests from `libtool-macros.log', and all the logs of gettext tests + from `gettext-macros.log'. + 2011-12-10 Stefano Lattarini <stefano.lattarini <at> gmail.com> release: don't run "make distcheck" automatically diff --git a/tests/Makefile.am b/tests/Makefile.am index 831906b..d6a15f7 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -924,6 +924,68 @@ yflags.test \ yflags2.test \ $(parallel_tests) +# FIXME: make these automatically computed once we are merged into +# FIXME: the `testsuite-work' branch. +depcomp4.log: libtool-macros.log +depcomp7.log: libtool-macros.log +depcomp8b.log: libtool-macros.log +fort5.log: libtool-macros.log +instdir-ltlib.log: libtool-macros.log +instfail-libtool.log: libtool-macros.log +ldadd.log: libtool-macros.log +ldflags.log: libtool-macros.log +libobj13.log: libtool-macros.log +libtoo10.log: libtool-macros.log +libtoo11.log: libtool-macros.log +libtool.log: libtool-macros.log +libtool2.log: libtool-macros.log +libtool3.log: libtool-macros.log +libtool5.log: libtool-macros.log +libtool6.log: libtool-macros.log +libtool7.log: libtool-macros.log +libtool8.log: libtool-macros.log +libtool9.log: libtool-macros.log +listval.log: libtool-macros.log +ltcond.log: libtool-macros.log +ltcond2.log: libtool-macros.log +ltconv.log: libtool-macros.log +ltdeps.log: libtool-macros.log +ltinit.log: libtool-macros.log +ltinstloc.log: libtool-macros.log +ltlibobjs.log: libtool-macros.log +ltlibsrc.log: libtool-macros.log +ltorder.log: libtool-macros.log +nobase-libtool.log: libtool-macros.log +pr211.log: libtool-macros.log +pr300-ltlib.log: libtool-macros.log +pr307.log: libtool-macros.log +pr401b.log: libtool-macros.log +pr72.log: libtool-macros.log +reqd2.log: libtool-macros.log +silent3.log: libtool-macros.log +silent4.log: libtool-macros.log +silent9.log: libtool-macros.log +stdlib2.log: libtool-macros.log +strip3.log: libtool-macros.log +subobj9.log: libtool-macros.log +suffix10.log: libtool-macros.log +suffix2.log: libtool-macros.log +suffix5.log: libtool-macros.log +suffix8.log: libtool-macros.log +vala.log: libtool-macros.log +vala1.log: libtool-macros.log +vala2.log: libtool-macros.log +vala3.log: libtool-macros.log +vala4.log: libtool-macros.log +vala5.log: libtool-macros.log + +# FIXME: make these automatically computed once we are merged into +# FIXME: the `testsuite-work' branch. +gettext.log: gettext-macros.log +gettext2.log: gettext-macros.log +gettext3.log: gettext-macros.log +subcond.log: gettext-macros.log + EXTRA_DIST = ChangeLog-old gen-parallel-tests $(TESTS) distcheck-missing-m4.log distcheck-outdated-m4.log: distcheck-hook-m4.am diff --git a/tests/Makefile.in b/tests/Makefile.in index 3ad0146..adbd77e 100644 --- a/tests/Makefile.in +++ b/tests/Makefile.in @@ -1547,6 +1547,68 @@ $(parallel_tests): $(parallel_tests:-p.test=.test) Makefile.am < $(srcdir)/$$input >$@ chmod a+rx $@ +# FIXME: make these automatically computed once we are merged into +# FIXME: the `testsuite-work' branch. +depcomp4.log: libtool-macros.log +depcomp7.log: libtool-macros.log +depcomp8b.log: libtool-macros.log +fort5.log: libtool-macros.log +instdir-ltlib.log: libtool-macros.log +instfail-libtool.log: libtool-macros.log +ldadd.log: libtool-macros.log +ldflags.log: libtool-macros.log +libobj13.log: libtool-macros.log +libtoo10.log: libtool-macros.log +libtoo11.log: libtool-macros.log +libtool.log: libtool-macros.log +libtool2.log: libtool-macros.log +libtool3.log: libtool-macros.log +libtool5.log: libtool-macros.log +libtool6.log: libtool-macros.log +libtool7.log: libtool-macros.log +libtool8.log: libtool-macros.log +libtool9.log: libtool-macros.log +listval.log: libtool-macros.log +ltcond.log: libtool-macros.log +ltcond2.log: libtool-macros.log +ltconv.log: libtool-macros.log +ltdeps.log: libtool-macros.log +ltinit.log: libtool-macros.log +ltinstloc.log: libtool-macros.log +ltlibobjs.log: libtool-macros.log +ltlibsrc.log: libtool-macros.log +ltorder.log: libtool-macros.log +nobase-libtool.log: libtool-macros.log +pr211.log: libtool-macros.log +pr300-ltlib.log: libtool-macros.log +pr307.log: libtool-macros.log +pr401b.log: libtool-macros.log +pr72.log: libtool-macros.log +reqd2.log: libtool-macros.log +silent3.log: libtool-macros.log +silent4.log: libtool-macros.log +silent9.log: libtool-macros.log +stdlib2.log: libtool-macros.log +strip3.log: libtool-macros.log +subobj9.log: libtool-macros.log +suffix10.log: libtool-macros.log +suffix2.log: libtool-macros.log +suffix5.log: libtool-macros.log +suffix8.log: libtool-macros.log +vala.log: libtool-macros.log +vala1.log: libtool-macros.log +vala2.log: libtool-macros.log +vala3.log: libtool-macros.log +vala4.log: libtool-macros.log +vala5.log: libtool-macros.log + +# FIXME: make these automatically computed once we are merged into +# FIXME: the `testsuite-work' branch. +gettext.log: gettext-macros.log +gettext2.log: gettext-macros.log +gettext3.log: gettext-macros.log +subcond.log: gettext-macros.log + distcheck-missing-m4.log distcheck-outdated-m4.log: distcheck-hook-m4.am clean-local: clean-local-check diff --git a/tests/defs.in b/tests/defs.in index f24d2ad..a938675 100644 --- a/tests/defs.in +++ b/tests/defs.in @@ -443,47 +443,8 @@ unset VERBOSE echo "=== Running test $0" # We might need extra macros, e.g., from Libtool or Gettext. -# Find them on the system. -# Use `-I $srcdir/../m4' in addition to `--acdir=$srcdir/../m4', because the -# other `-I' directories added for libtool and gettext might contain -# files from an old version of Automake that we don't want to use. -# Use `-Wno-syntax' because we do not want our test suite to fail because -# some third-party .m4 file is underquoted. -case $required in - *libtool* | *gettext* ) - aclocaldir='@prefix@/share/aclocal' - extra_includes="" - if test -f $aclocaldir/dirlist; then - extra_includes=` - <$aclocaldir/dirlist \ - sed 's/#.*//;s/[ ][ ]*$//g' \ - | while read dir; do test ! -d "$dir" || echo "-I $dir"; done` - else :; fi - - libtool_found=no - gettext_found=no - for d in $extra_includes $aclocaldir ; do - test "x$d" != x-I || continue - if test -f "$d/libtool.m4"; then - libtool_found=yes - fi - if test -f "$d/gettext.m4"; then - gettext_found=yes - fi - done - case $required in - *libtool* ) test $libtool_found = yes || Exit 77 ;; - *gettext* ) test $gettext_found = yes || Exit 77 ;; - esac - # Libtool cannot cope with spaces in the build tree. Our testsuite setup - # cannot cope with spaces in the source tree name for Libtool and gettext - # tests. - case $srcdir,`pwd` in - *\ * | *\ *) Exit 77 ;; - esac - ACLOCAL="$ACLOCAL -Wno-syntax -I $srcdir/../m4 $extra_includes -I $aclocaldir" - ;; -esac +case " $required " in *\ libtool*) . ../libtool-macros.dir/get.sh;; esac +case " $required " in *\ gettext*) . ../gettext-macros.dir/get.sh;; esac testaclocaldir='@abs_top_srcdir@/m4' diff --git a/tests/gettext-macros.test b/tests/gettext-macros.test new file mode 100755 index 0000000..7fe1274 --- /dev/null +++ b/tests/gettext-macros.test @@ -0,0 +1,80 @@ +#! /bin/sh +# Copyright (C) 2011 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Try to find the gettext `.m4' files and make them easily accessed +# to the test cases requiring them. +# See also automake bug#9807. + +. ./defs || Exit 1 + +echo "# Automatically generated by $me." > get.sh +echo : >> get.sh + +# The `gettextize' and `autopoint' scripts will look into Makefile.am. +echo ACLOCAL_AMFLAGS = -I m4 > Makefile.am + +# Required by autopoint. +echo 'AM_GNU_GETTEXT' > configure.in +# Likewise; and older version specified here *won't* work! +echo 'AM_GNU_GETTEXT_VERSION([0.10.35])' >> configure.in + +# Prefer autopoint to gettextize, since the more modern versions of the +# latter might unconditionally require user interaction to complete; +# yes, this means confirmation from /dev/tty (!) -- see: +# <http://lists.gnu.org/archive/html/bug-gettext/2011-12/msg00000.html> +# Since this "forced interaction" behaviour of gettextize wasn't present +# before the introduction of autopoint, we should be able to safely +# fall back to calling gettextize non-interactively if autopoint is not +# present. +if autopoint --version; then + am_gettextize_command=autopoint +else + am_gettextize_command=gettextize +fi + +if $am_gettextize_command --force && test -f m4/gettext.m4; then + unindent >> get.sh <<END + ACLOCAL_PATH="`pwd`/m4":\$ACLOCAL_PATH + export ACLOCAL_PATH +END +else + # Older versions of gettext might not have a gettextize program + # available, but this doesn't mean the user hasn't made the gettext + # macros available, e.g., by properly setting ACLOCAL_PATH. + rm -rf m4 + mkdir m4 + # See below for an explanation about the use the of `-Wno-syntax'. + if $ACLOCAL -Wno-syntax -I m4 --install && test -f m4/gettext.m4; then + : # Gettext macros already accessible by default. + else + echo "skip_ \"couldn't find or get gettext macros\"" >> get.sh + fi +fi + +. ./get.sh + +$ACLOCAL --force -I m4 || cat >> get.sh <<'END' +# We need to use `-Wno-syntax', since we do not want our test suite +# to fail merely because some third-party `.m4' file is underquoted. +ACLOCAL="$ACLOCAL -Wno-syntax" +END + +# The file gettextize or autopoint might have copied in the `m4' +# subdirectory of the test directory are going to be needed by +# other tests, so we must not remove the test directory. +keep_testdirs=yes + +: diff --git a/tests/libtool-macros.test b/tests/libtool-macros.test new file mode 100755 index 0000000..31e5019 --- /dev/null +++ b/tests/libtool-macros.test @@ -0,0 +1,62 @@ +#! /bin/sh +# Copyright (C) 2011 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Try to find the libtool `.m4' files and make them easily accessed +# to the test cases requiring them. +# See also automake bug#9807. + +. ./defs || Exit 1 + +echo "# Automatically generated by $me." > get.sh +echo : >> get.sh + +# The `libtoolize' script will look into Makefile.am. +echo ACLOCAL_AMFLAGS = -I m4 > Makefile.am + +if libtoolize --copy --install && test -f m4/libtool.m4; then + unindent >> get.sh <<END + ACLOCAL_PATH="`pwd`/m4":\$ACLOCAL_PATH + export ACLOCAL_PATH +END +else + # Libtoolize from libtool < 2.0 didn't support the `--install' option, + # but this doesn't mean the user hasn't made the libtool macros + # available, e.g., by properly setting ACLOCAL_PATH. + rm -rf m4 + mkdir m4 + echo AC_PROG_LIBTOOL >> configure.in + # See below for an explanation about the use the of `-Wno-syntax'. + if $ACLOCAL -Wno-syntax -I m4 --install && test -f m4/libtool.m4; then + : # Libtool macros already accessible by default. + else + echo "skip_ \"couldn't find or get libtool macros\"" >> get.sh + fi +fi + +. ./get.sh + +$ACLOCAL --force -I m4 || cat >> get.sh <<'END' +# We need to use `-Wno-syntax', since we do not want our test suite +# to fail merely because some third-party `.m4' file is underquoted. +ACLOCAL="$ACLOCAL -Wno-syntax" +END + +# The file libtoolize might have just copied in the `m4' subdirectory of +# the test directory are going to be needed by other tests, so we must +# not remove the test directory. +keep_testdirs=yes + +: -- 1.7.2.3
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to control <at> debbugs.gnu.org
.
(Thu, 22 Dec 2011 12:10:02 GMT) Full text and rfc822 format available.Stefano Lattarini <stefano.lattarini <at> gmail.com>
:Peter Rosin <peda <at> lysator.liu.se>
:Message #33 received at 9807-done <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: automake-patches <at> gnu.org Cc: 9807-done <at> debbugs.gnu.org Subject: Re: bug#9807: [PATCH] {maint} tests: better handling of gettext and libtool requirements Date: Thu, 22 Dec 2011 18:47:56 +0100
On 12/14/2011 02:06 PM, Stefano Lattarini wrote: > This change fixes automake bug#9807. > I've squashed in the fixlet below, tested the patch on NetBSD 5.1 for good measure (the libtool tests that were by default being skipped there started to run and pass, yay!), and pushed to maint. I'm thus closing this bug report. Thanks, Stefano -*-*-*- diff --git a/ChangeLog b/ChangeLog index 4d951a0..77afab4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -68,6 +68,7 @@ * tests/Makefile.am: Declare dependency of all the logs of libtool tests from `libtool-macros.log', and all the logs of gettext tests from `gettext-macros.log'. + (TESTS): Add the new tests. 2011-12-22 Stefano Lattarini <stefano.lattarini <at> gmail.com> diff --git a/tests/Makefile.am b/tests/Makefile.am index 266db46..b2a61ec 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -924,6 +924,8 @@ yaccvpath.test \ yacc-dist-nobuild-subdir.test \ yflags.test \ yflags2.test \ +libtool-macros.test \ +gettext-macros.test \ $(parallel_tests) # FIXME: make these automatically computed once we are merged into
bug-automake <at> gnu.org
:bug#9807
; Package automake
.
(Sat, 24 Dec 2011 09:44:02 GMT) Full text and rfc822 format available.Message #36 received at 9807 <at> debbugs.gnu.org (full text, mbox):
From: Stefano Lattarini <stefano.lattarini <at> gmail.com> To: 9807 <at> debbugs.gnu.org Subject: Re: bug#9807: [PATCH] {maint} tests: better handling of gettext and libtool requirements Date: Sat, 24 Dec 2011 10:40:59 +0100
On 12/22/2011 06:47 PM, Stefano Lattarini wrote: > On 12/14/2011 02:06 PM, Stefano Lattarini wrote: >> This change fixes automake bug#9807. >> > I've squashed in the fixlet below, tested the patch on NetBSD 5.1 for good > measure (the libtool tests that were by default being skipped there started > to run and pass, yay!), and pushed to maint. > > I'm thus closing this bug report. > > Thanks, > Stefano > The applied patch wasn't 100% correct unfortunately, and was causing some gettext tests to be skipped without a good reason. I've fixed that problem with the follow-up commits `v1.11-582-g763f3ec' and `v1.11-583-ge1fad75': <http://lists.gnu.org/archive/html/automake-patches/2011-12/msg00171.html> <http://lists.gnu.org/archive/html/automake-patches/2011-12/msg00173.html> Regards, Stefano
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Sat, 21 Jan 2012 12:24:03 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.