GNU bug report logs - #9807
libtool is not found by the automake testsuite

Previous Next

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


Report forwarded to bug-automake <at> gnu.org:
bug#9807; Package automake. (Thu, 20 Oct 2011 12:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Rosin <peda <at> lysator.liu.se>:
New bug report received and forwarded. Copy sent to 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




Information forwarded to 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




Information forwarded to bug-automake <at> gnu.org:
bug#9807; Package automake. (Thu, 20 Oct 2011 13:22:02 GMT) Full text and rfc822 format available.

Information forwarded to 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




Information forwarded to 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!




Information forwarded to 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




Information forwarded to 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)]

Information forwarded to 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





Added tag(s) patch. Request was from 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.

Reply sent to Stefano Lattarini <stefano.lattarini <at> gmail.com>:
You have taken responsibility. (Thu, 22 Dec 2011 17:51:02 GMT) Full text and rfc822 format available.

Notification sent to Peter Rosin <peda <at> lysator.liu.se>:
bug acknowledged by developer. (Thu, 22 Dec 2011 17:51:03 GMT) Full text and rfc822 format available.

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





Information forwarded to 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




bug archived. Request was from 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.

This bug report was last modified 13 years and 149 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.