bug#13928: Closing automake bug#13928 (bad interactions between 'subdir-object' option and automatic dependency tracking)
close 13928 thanks Reference: http://debbugs.gnu.org/13928 I've merged the latest patch series: http://lists.gnu.org/archive/html/automake-patches/2015-01/msg6.html into the 'minor' and 'master' branches, and the testsuite appears to be happy (or at least no more unhappy than before) on the following systems (in addition to GNU/Linux): - Solaris 10 - NetBSD 5.1 - FreeBSD 8.0 - AIX 7.1 I'm thus optimistically declaring victory on this long-standing issue. Hopefully I'll be able to release a new Automake minor version (1.16) containing this fix in the coming month or so. If in the meantime anyone feels patient enough to test the unreleased Automake from the 'minor' branch on real-world projects which were being bitten by the bug, I would be very grateful. Thanks, Stefano
bug#13928: [PATCH 0/4] Fix automake bug#13928
Stefano Lattarini (4):
deps: 'subdir-object' option now works when foo_SOURCES contains $(var)
tests: fix some bugs in an XFAILing test
compile: don't place built object files in $(srcdir), ever ...
deps: fix corner-case make distclean bug
NEWS | 43 +++
PLANS/subdir-objects.txt | 10 +--
THANKS| 1 +
bin/automake.in | 134 +++--
lib/am/configure.am | 6 +-
lib/am/depend.am | 14 +++-
m4/depout.m4 | 78 +--
m4/make.m4| 59 +++
t/depcomp8a.sh| 16 ++--
t/depcomp8b.sh| 16 ++--
t/{postproc.sh = depend-postproc.sh} | 29 ++-
t/extra-sources.sh| 5 +-
t/lex-depend-cxx.sh | 5 ++
t/lex-depend-grep.sh | 2 +-
t/list-of-tests.mk| 5 +-
t/pr224.sh| 4 +-
t/subobj-indir-pr13928.sh | 4 +-
t/subobj-pr13928-more-langs.sh| 138 ++
t/subobj-vpath-pr13928.sh | 89 +++---
t/subobj11b.sh| 10 +--
t/subobj11c.sh| 2 +-
21 files changed, 478 insertions(+), 192 deletions(-)
rename t/{postproc.sh = depend-postproc.sh} (68%)
create mode 100644 t/subobj-pr13928-more-langs.sh
--
2.1.3
bug#13928: [PATCH 1/4] deps: 'subdir-object' option now works when foo_SOURCES contains $(var)
Following a suggestions of Johan Kristensen, we have config.status use
'make' invocations rather than Makefile-parsing 'sed' hacks to bootstrap
the dependency-tracking '.Po' and '.Plo' makefile fragments. To handle
the inclusion of such files that are still missing when make is first
we basically generate a temporary Makefile without these includes, and
call 'make' on that Makefile.
This fixes the serious bug bug#13928, which was an hard blocker to make the
behavior mandated by the 'subdir-object' active by default (which we want
to do in Automake 2.0).
The issue has also been reported in bug#15919.
* NEWS, THANKS: Update.
* bin/automake.in (handle_languages): Add a trailing marking comment
(# am--include-marker) to the generated Makefile lines issuing 'include'
directives for the dependency-tracking '.Po' and '.Plo' makefile fragments.
Also rename the generated Makefile variable 'am__depfiles_maybe' to the
clearer 'am__maybe_remake_depfiles'.
Minor unrelated refactoring.
* lib/am/configure.am: Adjust to account for the 'am__depfiles_maybe' -
'am__maybe_remake_depfiles' renaming.
* lib/am/depend.am: Add rules to generate a dummy version of all the
dependency-tracking '.Po' and '.Plo' makefile fragments.
* m4/depout.m4: Use make invocations rather than Makefile-parsing sed hacks
to bootstrap the dependency-tracking '.Po' and '.Plo' makefile fragments.
We still use some sed trickery in order to remove the inclusion of the
still non existing .Po and .Plo files from the Makefile we invoke make
upon; this is done stripping lines that contain the magic string
# am--include-marker.
* m4/make.m4 (AM_MAKE_INCLUDE): Given that now automake generates Makefiles
containing include statements with trailing comment, adjust the checks done
here to make sure $MAKE support that; e.g., include foo.mk # comment
rather than just include foo.mk.
Also refactor and adjust to leave better debugging info in config.log.
* t/postproc.sh: Rename ...
* t/depend-postproc.sh: ... to this, and adjust and enhance.
* t/list-of-tests.mk (handwritten_TESTS): Adjust.
(XFAIL_TESTS): Remove 't/subobj-indir-pr13928.sh', which is now succeeding.
* t/subobj-indir-pr13928.sh: Simplify slightly, now that we expect it to
pass.
* t/depcomp8a.sh: Adjust grepping check to account for the changes in
the generated Makefile, and tp be somewhat more robust in light of possible
future modifications.
* t/depcomp8b.sh: Likewise.
* t/subobj11b.sh: Likewise.
* t/subobj11c.sh: Likewise.
* t/extra-sources.sh: Likewise.
* t/lex-depend-grep.sh: Likewise.
* t/lex-depend-cxx.sh: Add a command to help debugging in case of test
failure.
Helped-by: Johan Kristensen johankristen...@gmail.com
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 28
THANKS| 1 +
bin/automake.in | 84 ++-
lib/am/configure.am | 6 +--
lib/am/depend.am | 7 +++
m4/depout.m4 | 78 ++--
m4/make.m4| 59 +++-
t/depcomp8a.sh| 16 +++
t/depcomp8b.sh| 16 +++
t/{postproc.sh = depend-postproc.sh} | 29 ++--
t/extra-sources.sh| 5 ++-
t/lex-depend-cxx.sh | 5 +++
t/lex-depend-grep.sh | 2 +-
t/list-of-tests.mk| 3 +-
t/subobj-indir-pr13928.sh | 4 +-
t/subobj11b.sh| 10 ++---
t/subobj11c.sh| 2 +-
17 files changed, 203 insertions(+), 152 deletions(-)
rename t/{postproc.sh = depend-postproc.sh} (68%)
diff --git a/NEWS b/NEWS
index 84a5e0a..a930049 100644
--- a/NEWS
+++ b/NEWS
@@ -62,6 +62,34 @@
+New in 1.16:
+
+* Bugs fixed:
+
+ - Automatic dependency tracking has been fixed to work also when the
+subdir-object option is used and some 'foo_SOURCES' definition contains
+unexpanded references to make variables, as in, e.g.:
+
+a_src = sources/libs/aaa
+b_src = sources/bbb
+foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c
+
+With such a setup, the created makefile fragment containing dependency
+tracking information will be correctly placed under the directories
+named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
+mistakenly under directories named (literally!) '$(src_a)/.deps' and
+'$(src_b)/.deps' (this was automake bug#13928).
+
+Notice that in order to fix this bug we had to slightly change the
+semantics of how config.status bootstraps the makefile fragments
+required for the dependency tracking to work: rather than attempting
+to parse the Makefiles via grep and sed trickeries only, we actually
+invoke 'make' on a slightly preprocessed
bug#13928: [PATCH 4/4] deps: fix corner-case make distclean bug
Assume we have package satisfying the following conditions:
(1) automatic dependency tracking is enabled;
(2) the 'subdir-objects' Automake option is enabled;
(3) the package uses a recursive make setup.
Also assume that:
(a) a subdir Makefile declares a foo_SOURCES variable containing
a source file in the parent directory;
(b) that parent Makefile declare a compiled program itself.
Then BSD and Solaris make used to fail when running make distclean,
because the 'distclean' target of the subdir Makefile removed the
whole '.deps' directory before the parent Makefile was done with the
included '.Po' makefile fragments in that directory. This issue was
revealed by failures in the 'subobj-vpath-pr13928.sh' test when those
make implementations were used.
We fix the issue by ensuring the 'distclean' target of any Makefile
only removed the '.Po' makefile fragments included by it, rather than
the whole '.deps' directory where such files resides.
This change should be the last step in fixing automake bug#13928
for good.
* bin/automake.in (handle_languages), lib/am/depend.am: Adjust
to implement the new 'distclean' logic.
* t/pr224.sh: Adjust to avoid a spurious failure.
* PLANS/subdir-objects.txt: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
PLANS/subdir-objects.txt | 10 +++---
bin/automake.in | 20 ++--
lib/am/depend.am | 7 ---
t/pr224.sh | 4 ++--
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/PLANS/subdir-objects.txt b/PLANS/subdir-objects.txt
index 3cf6101..c849e33 100644
--- a/PLANS/subdir-objects.txt
+++ b/PLANS/subdir-objects.txt
@@ -5,9 +5,6 @@ We want to make the behaviour currently enabled by the
'subdir-objects'
the default one, and in fact the *only* one, in Automake 2.0.
See automake bug#13378: http://debbugs.gnu.org/13378.
-Sadly, **THIS IS IMPOSSIBLE** until automake bug#13928 is resolved:
-http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
-
Details
---
@@ -53,11 +50,10 @@ We also make sure to avoid the warning when it would be
irrelevant, i.e.,
if all source files sit in current directory (thanks to Peter Johansson
for suggesting this).
-For some automake 1.x (*before* 2.0 can be released)
-
+For automake 1.16 (*before* 2.0 can be released)
+
-Find a proper way to fix the blocking automake bug#13928:
-http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
+Submit the pending patch series that fixes http://debbugs.gnu.org/13928
For automake 2.0
diff --git a/bin/automake.in b/bin/automake.in
index d8ecca5..21cccbe 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1242,14 +1242,16 @@ sub handle_languages ()
INTERNAL);
define_variable ('am__maybe_remake_depfiles', 'depfiles',
INTERNAL);
define_variable ('am__depfiles_remade', @dep_files, INTERNAL);
-# Generate each 'include' directive individually. Several make
-# implementations (IRIX 6, Solaris 10, FreeBSD 8) will fail to
-# properly include several files resulting from a variable
-# expansion. Just Generating many separate includes seems thus
-# safest.
$output_rules .= \n;
+my @dist_rms;
foreach my $depfile (@dep_files)
{
+push @dist_rms, \t-rm -f $depfile;
+# Generate each 'include' directive individually. Several
+# make implementations (IRIX 6, Solaris 10, FreeBSD 8) will
+# fail to properly include several files resulting from a
+# variable expansion. Just Generating many separate includes
+# seems thus safest.
$output_rules .= subst ('AMDEP_TRUE') .
subst ('am__include') .
.
@@ -1262,11 +1264,9 @@ sub handle_languages ()
require_conf_file ($am_file.am, FOREIGN, 'depcomp');
-# Compute the set of directories to remove in distclean-depend.
-my @dep_dirs = uniq (map { dirname ($_) } @dep_files);
-$output_rules .= file_contents ('depend',
-new Automake::Location,
-DEPDIRS = @dep_dirs);
+$output_rules .= file_contents (
+'depend', new Automake::Location,
+'DISTRMS' = join (\n, @dist_rms));
}
}
else
diff --git a/lib/am/depend.am b/lib/am/depend.am
index 0b226b6..3813996 100644
--- a/lib/am/depend.am
+++ b/lib/am/depend.am
@@ -27,8 +27,9 @@ am--depfiles: $(am__depfiles_remade)
## erase them in -am or -recursive rules; that would prevent any other
## rules from being recursive (for instance multilib clean rules are
## recursive
bug#13928: [PATCH 2/4] tests: fix some bugs in an XFAILing test
* t/subobj-vpath-pr13928.sh: This one. The test would have failed (or hung!) even if the bug it was testing against were fixed. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/subobj-vpath-pr13928.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/subobj-vpath-pr13928.sh b/t/subobj-vpath-pr13928.sh index 9c78d2e..8c3a6c5 100644 --- a/t/subobj-vpath-pr13928.sh +++ b/t/subobj-vpath-pr13928.sh @@ -33,7 +33,7 @@ AUTOMAKE_OPTIONS = subdir-objects noinst_PROGRAMS = test test_SOURCES = $(srcdir)/test.c test-objs: - test ! -f $(srcdir)/test.$(OBJEXT) + test ! -f '@srcdir@/test.$(OBJEXT)' test -f test.$(OBJEXT) END @@ -42,7 +42,7 @@ $ACLOCAL $AUTOCONF $AUTOMAKE -a || fatal_ autotools failed $EGREP 'test\.|DEPDIR|dirstamp|srcdir' Makefile.in || : # For debugging. $EGREP '\$.srcdir./test\.[o$]' Makefile.in exit 1 $FGREP '$(srcdir)/$(am__dirstamp)' Makefile.in exit 1 -$FGREP '$(srcdir)/$(DEPDIR)' exit 1 +$FGREP '$(srcdir)/$(DEPDIR)' Makefile.in exit 1 cat test.c 'END' int main (void) -- 2.1.3
bug#13928: [PATCH 3/4] compile: don't place built object files in $(srcdir), ever ...
... even when a source file is specified as '$(srdir)/foo.c' or
'$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile
fragments (those under '.deps' directories).
Such issues used to occur when the 'subdir-objects' option was given.
This change should fix the second and last part of automake bug#13928.
See also bug#16375 and bug#15293.
* NEWS: Update.
* bin/automake.in (handle_single_transform): Make sure object files
and dependency-tracking makefile fragments coming from source like
'$(srcdir)/foo.c' and '$(top_srcdir)/bar.c' are placed respectively
under $(builddir) and $(top_builddir).
* t/subobj-vpath-pr13928.sh: Enhance to expose even more aspects
of the bug we've just fixed.
* t/subobj-pr13928-more-langs.sh: New test, similar to the one above,
but with non-C languages as well.
* t/list-of-tests.mk (XFAIL_TESTS): Remove 'subobj-vpath-pr13928.sh',
it's now supposed to pass.
(handwritten_TESTS): Add 'subobj-pr13928-more-langs.sh'.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 21 ++-
bin/automake.in| 50 ++-
t/list-of-tests.mk | 2 +-
t/subobj-pr13928-more-langs.sh | 138 +
t/subobj-vpath-pr13928.sh | 89 ++
5 files changed, 269 insertions(+), 31 deletions(-)
create mode 100644 t/subobj-pr13928-more-langs.sh
diff --git a/NEWS b/NEWS
index a930049..eb3bc6f 100644
--- a/NEWS
+++ b/NEWS
@@ -67,8 +67,8 @@ New in 1.16:
* Bugs fixed:
- Automatic dependency tracking has been fixed to work also when the
-subdir-object option is used and some 'foo_SOURCES' definition contains
-unexpanded references to make variables, as in, e.g.:
+'subdir-object' option is used and some 'foo_SOURCES' definition
+contains unexpanded references to make variables, as in, e.g.:
a_src = sources/libs/aaa
b_src = sources/bbb
@@ -78,7 +78,7 @@ New in 1.16:
tracking information will be correctly placed under the directories
named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
mistakenly under directories named (literally!) '$(src_a)/.deps' and
-'$(src_b)/.deps' (this was automake bug#13928).
+'$(src_b)/.deps' (this was the first part of automake bug#13928).
Notice that in order to fix this bug we had to slightly change the
semantics of how config.status bootstraps the makefile fragments
@@ -88,6 +88,21 @@ New in 1.16:
using a private target that is only meant to bootstrap the required
makefile fragments.
+ - The 'subdir-object' option no longer causes object files corresponding
+to source files specified with an explicit '$(srcdir)' component to be
+placed in the source tree rather than in the build tree.
+
+For example, if Makefile.am contains:
+
+AUTOMAKE_OPTIONS = subdir-objects
+foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
+
+then make all will create 'foo.o' and 's/bar.o' in $(builddir) rather
+than in $(srcdir), and will create 'baz.o' in $(top_builddir) rather
+than in $(top_srcdir).
+
+This was the second part of automake bug#13928.
+
New in 1.15:
diff --git a/bin/automake.in b/bin/automake.in
index f19be92..d8ecca5 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1617,9 +1617,9 @@ sub handle_single_transform
my $renamed = 0;
my ($linker, $object);
- # This records whether we've seen a derived source file (e.g.
- # yacc output).
- my $derived_source = 0;
+# This records whether we've seen a derived source file (e.g., yacc
+# or lex output).
+my $derived_source;
# This holds the 'aggregate context' of the file we are
# currently examining. If the file is compiled with
@@ -1667,17 +1667,36 @@ sub handle_single_transform
# Now extract linker and other info.
$linker = $lang-linker;
- my $this_obj_ext;
- if (defined $source_extension)
- {
- $this_obj_ext = $source_extension;
- $derived_source = 1;
- }
- else
- {
- $this_obj_ext = $obj;
- }
- $object = $base . $this_obj_ext;
+my $this_obj_ext;
+if (defined $source_extension)
+ {
+$this_obj_ext = $source_extension;
+$derived_source = 1;
+ }
+else
+ {
+$this_obj_ext = $obj;
+$derived_source = 0;
+# Don't ever place built object files in $(srcdir),
+# even when sources are specified explicitly as (say)
+# '$(srcdir)/foo.c' or '$(top_srcdir)/foo.c'.
+# See automake bug#13928.
+my @d = split '/', $directory
bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
[I once again have to correct myself, sigh]
On 01/03/2015 02:14 AM, Stefano Lattarini wrote:
On 01/03/2015 12:23 AM, Stefano Lattarini wrote:
Hi Eric.
On 01/03/2015 12:14 AM, Eric Blake wrote:
On 01/02/2015 11:49 AM, Stefano Lattarini wrote:
... even when a source file is specified as '$(srdir)/foo.c' or
'$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile
fragments (those under '.deps' directories).
+++ b/NEWS
@@ -88,6 +88,21 @@ New in 1.16:
using a private target that is only meant to bootstrap the required
makefile fragments.
+ - The 'subdir-object' option no longer causes object files corresponding
+to source files specified with an explicit '$(srcdir)' component to be
+placed in the source tree rather than in the build tree.
+
+For example, if Makefile.am contains:
+
+AUTOMAKE_OPTIONS = subdir-objects
+foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
+
+then make all will create 'foo.o' and 's/bar.o' $(builddir) rather
s|'s/bar.o'|'s/bar.o' in|
Thanks, will fix before merging this in a non-rewindable branch (that
can't happen before Automake 1.16 is released anyway).
+than in $(srcdir), and 'baz.o' in $(top_builddir) rather than in
+$(top_srcdir).
+
+This was the second part of automake bug#13928.
+
And thanks for tackling this!
Wait to thank me, I've found another pre-existing bug in this area, affecting
non-GNU makes :-/ And by that I mean non-borked ones, like BSD make and
Solaris 10 CCS make.
On the plus side, the bug only affects make distclean (causing spurious
failures), and only for packages using a recursive setup and referencing
source files in a parent directory from a subdir Make; so it's a minor one.
On the negative side, I probably introduced it myself in some 1.12.x
release...
Nope, it was pre-existing. And I appear to have found an easy enough
fix for it; I will soon post a patch if the testsuite is happy on BSD
and Solaris.
Hopefully I'll have a fix in a week or so (I'll be AFK for most time in the
coming days).
Also, it appears this is causing another new testsuite failure with BSD make.
The following squash-in diff seems to take care of that:
-*-*-*-
diff --git a/bin/automake.in b/bin/automake.in
index f4327fc..0c44703 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1677,12 +1677,15 @@ sub handle_single_transform
{
$this_obj_ext = $obj;
$derived_source = 0;
-# Don't ever place built object files in $(srcdir), even when
-# sources are specified explicitly as (say) '$(srcdir)/foo.c'
-# or '$(top_srcdir)/foo.c'. See automake bug#13928.
-my @d = split '/', $directory;
-if (@d)
+do
{
+last unless option 'subdir-objects';
+# Don't ever place built object files in $(srcdir),
+# even when sources are specified explicitly as (say)
+# '$(srcdir)/foo.c' or '$(top_srcdir)/foo.c'.
+# See automake bug#13928.
+my @d = split '/', $directory;
+last unless @d;
my $d = $d[0];
if ($d eq '$(srcdir)' or $d eq '${srcdir}')
{
@@ -1690,7 +1693,7 @@ sub handle_single_transform
}
elsif ($d eq '$(top_srcdir)' or $d eq '${top_srcdir}')
{
- $d[0] = '$(top_builddir)';
+$d[0] = '$(top_builddir)';
}
$directory = join '/', @d;
}
-*-*-*-
This change was serious bugged BTW. I've now fixed it, but rather than
posting another squash-in, I will re-post the whole adjust patch series
once I've made sure there are no regressions on an of the UNIX flavors
I can test with (GNU/Linux, Solaris 10, AIX 7.1, NetBSD 5.1, FreeBSD 8.0)
Regards,
Stefano
bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
... even when a source file is specified as '$(srdir)/foo.c' or
'$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile
fragments (those under '.deps' directories).
Such issues used to occur when the 'subdir-objects' option was given.
This change should fix the second and last part of automake bug#13928.
See also bug#16375 and bug#15293.
* NEWS: Update.
* bin/automake.in (handle_single_transform): Make sure object files
and dependency-tracking makefile fragments coming from source like
'$(srcdir)/foo.c' and '$(top_srcdir)/bar.c' are placed respectively
under $(builddir) and $(top_builddir).
* t/subobj-vpath-pr13928.sh: Enhance to expose even more aspects
of the bug we've just fixed.
* t/subobj-pr13928-more-langs.sh: New test, similar to the one above,
but with non-C languages as well.
* t/list-of-tests.mk (XFAIL_TESTS): Remove 'subobj-vpath-pr13928.sh',
it's now supposed to pass.
(handwritten_TESTS): Add 'subobj-pr13928-more-langs.sh'.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 21 ++-
bin/automake.in| 49 ++-
t/list-of-tests.mk | 2 +-
t/subobj-pr13928-more-langs.sh | 138 +
t/subobj-vpath-pr13928.sh | 89 ++
5 files changed, 268 insertions(+), 31 deletions(-)
create mode 100644 t/subobj-pr13928-more-langs.sh
diff --git a/NEWS b/NEWS
index a930049..6355f74 100644
--- a/NEWS
+++ b/NEWS
@@ -67,8 +67,8 @@ New in 1.16:
* Bugs fixed:
- Automatic dependency tracking has been fixed to work also when the
-subdir-object option is used and some 'foo_SOURCES' definition contains
-unexpanded references to make variables, as in, e.g.:
+'subdir-object' option is used and some 'foo_SOURCES' definition
+contains unexpanded references to make variables, as in, e.g.:
a_src = sources/libs/aaa
b_src = sources/bbb
@@ -78,7 +78,7 @@ New in 1.16:
tracking information will be correctly placed under the directories
named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
mistakenly under directories named (literally!) '$(src_a)/.deps' and
-'$(src_b)/.deps' (this was automake bug#13928).
+'$(src_b)/.deps' (this was the first part of automake bug#13928).
Notice that in order to fix this bug we had to slightly change the
semantics of how config.status bootstraps the makefile fragments
@@ -88,6 +88,21 @@ New in 1.16:
using a private target that is only meant to bootstrap the required
makefile fragments.
+ - The 'subdir-object' option no longer causes object files corresponding
+to source files specified with an explicit '$(srcdir)' component to be
+placed in the source tree rather than in the build tree.
+
+For example, if Makefile.am contains:
+
+AUTOMAKE_OPTIONS = subdir-objects
+foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
+
+then make all will create 'foo.o' and 's/bar.o' $(builddir) rather
+than in $(srcdir), and 'baz.o' in $(top_builddir) rather than in
+$(top_srcdir).
+
+This was the second part of automake bug#13928.
+
New in 1.15:
diff --git a/bin/automake.in b/bin/automake.in
index f19be92..f4327fc 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1617,9 +1617,9 @@ sub handle_single_transform
my $renamed = 0;
my ($linker, $object);
- # This records whether we've seen a derived source file (e.g.
- # yacc output).
- my $derived_source = 0;
+# This records whether we've seen a derived source file (e.g., yacc
+# or lex output).
+my $derived_source;
# This holds the 'aggregate context' of the file we are
# currently examining. If the file is compiled with
@@ -1667,17 +1667,35 @@ sub handle_single_transform
# Now extract linker and other info.
$linker = $lang-linker;
- my $this_obj_ext;
- if (defined $source_extension)
- {
- $this_obj_ext = $source_extension;
- $derived_source = 1;
- }
- else
- {
- $this_obj_ext = $obj;
- }
- $object = $base . $this_obj_ext;
+my $this_obj_ext;
+if (defined $source_extension)
+ {
+$this_obj_ext = $source_extension;
+$derived_source = 1;
+ }
+else
+ {
+$this_obj_ext = $obj;
+$derived_source = 0;
+# Don't ever place built object files in $(srcdir), even when
+# sources are specified explicitly as (say) '$(srcdir)/foo.c'
+# or '$(top_srcdir)/foo.c'. See automake bug#13928.
+my @d = split '/', $directory;
+if (@d
bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
On 01/03/2015 12:23 AM, Stefano Lattarini wrote:
Hi Eric.
On 01/03/2015 12:14 AM, Eric Blake wrote:
On 01/02/2015 11:49 AM, Stefano Lattarini wrote:
... even when a source file is specified as '$(srdir)/foo.c' or
'$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile
fragments (those under '.deps' directories).
+++ b/NEWS
@@ -88,6 +88,21 @@ New in 1.16:
using a private target that is only meant to bootstrap the required
makefile fragments.
+ - The 'subdir-object' option no longer causes object files corresponding
+to source files specified with an explicit '$(srcdir)' component to be
+placed in the source tree rather than in the build tree.
+
+For example, if Makefile.am contains:
+
+AUTOMAKE_OPTIONS = subdir-objects
+foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
+
+then make all will create 'foo.o' and 's/bar.o' $(builddir) rather
s|'s/bar.o'|'s/bar.o' in|
Thanks, will fix before merging this in a non-rewindable branch (that
can't happen before Automake 1.16 is released anyway).
+than in $(srcdir), and 'baz.o' in $(top_builddir) rather than in
+$(top_srcdir).
+
+This was the second part of automake bug#13928.
+
And thanks for tackling this!
Wait to thank me, I've found another pre-existing bug in this area, affecting
non-GNU makes :-/ And by that I mean non-borked ones, like BSD make and
Solaris 10 CCS make.
On the plus side, the bug only affects make distclean (causing spurious
failures), and only for packages using a recursive setup and referencing
source files in a parent directory from a subdir Make; so it's a minor one.
On the negative side, I probably introduced it myself in some 1.12.x
release...
Hopefully I'll have a fix in a week or so (I'll be AFK for most time in the
coming days).
Also, it appears this is causing another new testsuite failure with BSD make.
The following squash-in diff seems to take care of that:
-*-*-*-
diff --git a/bin/automake.in b/bin/automake.in
index f4327fc..0c44703 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1677,12 +1677,15 @@ sub handle_single_transform
{
$this_obj_ext = $obj;
$derived_source = 0;
-# Don't ever place built object files in $(srcdir), even when
-# sources are specified explicitly as (say) '$(srcdir)/foo.c'
-# or '$(top_srcdir)/foo.c'. See automake bug#13928.
-my @d = split '/', $directory;
-if (@d)
+do
{
+last unless option 'subdir-objects';
+# Don't ever place built object files in $(srcdir),
+# even when sources are specified explicitly as (say)
+# '$(srcdir)/foo.c' or '$(top_srcdir)/foo.c'.
+# See automake bug#13928.
+my @d = split '/', $directory;
+last unless @d;
my $d = $d[0];
if ($d eq '$(srcdir)' or $d eq '${srcdir}')
{
@@ -1690,7 +1693,7 @@ sub handle_single_transform
}
elsif ($d eq '$(top_srcdir)' or $d eq '${top_srcdir}')
{
- $d[0] = '$(top_builddir)';
+$d[0] = '$(top_builddir)';
}
$directory = join '/', @d;
}
-*-*-*-
I will re-run the whole testsuite with all the affected make implementations
in the coming days, to make sure this change doesn't introduce new failures.
Sorry for the noise,
Stefano
bug#13928: [PATCH] compile: don't place built object files in $(srcdir), ever ...
Hi Eric. On 01/03/2015 12:14 AM, Eric Blake wrote: On 01/02/2015 11:49 AM, Stefano Lattarini wrote: ... even when a source file is specified as '$(srdir)/foo.c' or '$(top_srcdir)/bar.c'. And ditto for dependency-tracking makefile fragments (those under '.deps' directories). +++ b/NEWS @@ -88,6 +88,21 @@ New in 1.16: using a private target that is only meant to bootstrap the required makefile fragments. + - The 'subdir-object' option no longer causes object files corresponding +to source files specified with an explicit '$(srcdir)' component to be +placed in the source tree rather than in the build tree. + +For example, if Makefile.am contains: + +AUTOMAKE_OPTIONS = subdir-objects +foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c + +then make all will create 'foo.o' and 's/bar.o' $(builddir) rather s|'s/bar.o'|'s/bar.o' in| Thanks, will fix before merging this in a non-rewindable branch (that can't happen before Automake 1.16 is released anyway). +than in $(srcdir), and 'baz.o' in $(top_builddir) rather than in +$(top_srcdir). + +This was the second part of automake bug#13928. + And thanks for tackling this! Wait to thank me, I've found another pre-existing bug in this area, affecting non-GNU makes :-/ And by that I mean non-borked ones, like BSD make and Solaris 10 CCS make. On the plus side, the bug only affects make distclean (causing spurious failures), and only for packages using a recursive setup and referencing source files in a parent directory from a subdir Make; so it's a minor one. On the negative side, I probably introduced it myself in some 1.12.x release... Hopefully I'll have a fix in a week or so (I'll be AFK for most time in the coming days).
bug#13928: The 'subdir-object' option breaks makefiles where foo_SOURCES contains $(var)
On 01/02/2015 02:16 AM, Harlan Stenn wrote: Excellent timing, thanks! Now that ntp-4.2.8 is settling down, I'm looking to update our Makefile.am's to use subdir-objects, and it's not being fun. (An aside: I see that ntp still uses a recursive Makefile setup. Given that you are about to mess with the ntp build system anyway, have you thought about trying to convert it to a non-recursive make setup? That is the suggested way to go nowadays...) I may wait until 1.15 is released to continue this effort. Well, actually, Automake 1.15 is already tagged in the Git repository and ready to be released (as soon as my new GPG key, replacing the one that expired 2 months ago, will be accepted by fpt-upl...@gnu.org). So this patch will not be available before Automake 1.16. But then again, I believe the fix for this bug alone would be enough to justify a new minor Automake release, so don't worry, this fix will go in some release soon enough :-) Also, more importantly, notice that this patch do not yet solve the issue of '.deps' directories and object files being created in the source directory (rather than in the build directory) for source files that contains an explicit reference to $(srcdir), when the 'subdir-object' option is enabled; see the still XFAIL'ing test 't/subobj-vpath-pr13928.sh'. This issue should *hopefully* be easy to fix, especially with the new dependency-bootstrapping logic; and I will try hard to make that happen before the 1.16 release. Thanks, Stefano
bug#13928: The 'subdir-object' option breaks makefiles where foo_SOURCES contains $(var)
retitle 13928 foo_SOURCES containing unexpanded $(var) breaks with 'subdir-object' option active stop Reference: http://debbugs.gnu.org/13928 Hi Johan and everybody, sorry for the awful delay. On 07/05/2014 07:59 PM, Johan Kristensen wrote: Hi, What is the current status of this bug? [MEGA-SNIP] I'm trying a simple approach (which seems quite promising so far) in the experimental Git branch experimental/deps-pr13928-take-2. The new code seems to work with the following make versions: - GNU - NetBSD 5.1 - FreeBSD 8.0 - Solaris 10 - AIX 7.1 Notice that the new code will not land in Automake 1.15 (that I hope to be able to release in less than a week, as soon as my new GPG key is accepted by ftp-upl...@gnu.org). But unless any unanticipated issue arises, I definitely want the fix to land in Automake 1.16 (and the fix for this bug alone would IMHO be enough to justify a new minor release). Thanks, Stefano
bug#18286: [PATCH 2/2] dist: fix bug#18286 distcheck fails to detect missing files
BTW, this issue had been already reported in the past: http://lists.gnu.org/archive/html/automake/2006-09/msg8.html http://lists.gnu.org/archive/html/automake/2013-01/msg00049.html make distcheck could sometimes fail to detect missing files in the distribution tarball, especially in those cases where both the generated files and their dependencies are explicitly in $(srcdir). An important example of this are *generated* makefile fragments included at Automake time in Makefile.am. A basic example: # -*- Makefile.am -*- $(srcdir)/fragment.am: $(srcdir)/data.txt $(srcdir)/preproc.sh cd $(srcdir) $(SHELL) preproc.sh data.txt fragment.am include $(srcdir)/fragment.am ... If the use forgot to add data.txt and/or preproc.sh in the distribution tarball, make distcheck would have erroneously succeeded! The reason is that, while $(srcdir)/data.txt does not exist, make also looks in $(srcdir)/$(srcdir)/data.txt, and in the distcheck-issued VPATH build where $(srcdir) is '..', that file exists, as it is part of the original development directory. * t/distdir.am (distcheck): Adjust to have the build directory be '$(distdir)/_build/sub' rather than just '$(distdir)/_build'. Thanks Nicola Fontana for the suggestion. * t/distcheck-pr18286.sh: Enhance and tighten a little. * t/list-of-tests.mk (XFAIL_TESTS): Remove 't/distcheck-pr18286.sh', as it's now passing. * t/subdir-am-cond.sh: Adjust to avoid a fully spurious failure due to the new distcheck semantics. * t/subdir-ac-subst.sh: Likewise. * t/dejagnu-relative-srcdir.sh: Likewise. * t/txinfo-builddir.sh: Likewise. * NEWS: Update. Helped-by: Nicola Fontana n...@entidi.it Helped-by: Peter Johansson troj...@gmail.com Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- NEWS | 16 THANKS | 1 + lib/am/distdir.am| 14 +- t/dejagnu-relative-srcdir.sh | 8 t/distcheck-pr18286.sh | 8 t/list-of-tests.mk | 1 - t/subdir-ac-subst.sh | 16 +--- t/subdir-am-cond.sh | 16 +--- t/txinfo-builddir.sh | 4 ++-- 9 files changed, 58 insertions(+), 26 deletions(-) diff --git a/NEWS b/NEWS index 1fae7ad..8f2d2a7 100644 --- a/NEWS +++ b/NEWS @@ -115,6 +115,22 @@ New in 1.14.2: something like ... overrides Automake target '$(srcdir)/foo.am. This bug is now fixed. + - Automake bug#18286: make distcheck could sometimes fail to detect +missing files in the distribution tarball, especially in those cases +where both the generated files and their dependencies are explicitly +in $(srcdir). An important example of this are *generated* makefile +fragments included at Automake time in Makefile.am; e.g.: + +... +$(srcdir)/fragment.am: $(srcdir)/data.txt $(srcdir)/preproc.sh +cd $(srcdir) $(SHELL) preproc.sh data.txt fragment.am +include $(srcdir)/fragment.am +... + +If the use forgot to add data.txt and/or preproc.sh in the distribution +tarball, make distcheck would have erroneously succeeded! This issue +is now fixed. + New in 1.14.1: diff --git a/THANKS b/THANKS index 6be803e..62f22f8 100644 --- a/THANKS +++ b/THANKS @@ -281,6 +281,7 @@ Nathanael Nerodenero...@twcny.rr.com Nelson H. F. Beebe be...@math.utah.edu Nicholas Wourms nwou...@netscape.net Nick Bowler nbow...@elliptictech.com +Nicola Fontana n...@entidi.it Nicolas Jolynj...@pasteur.fr Nicolas Thiery nthi...@icare.mines.edu NightStrike nightstr...@gmail.com diff --git a/lib/am/distdir.am b/lib/am/distdir.am index a8ad63c..6d9d42f 100644 --- a/lib/am/distdir.am +++ b/lib/am/distdir.am @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 2001-2013 Free Software Foundation, Inc. +## Copyright (C) 2001-2014 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 @@ -430,7 +430,7 @@ distcheck: dist ## can make our new subdirs. chmod -R a-w $(distdir) chmod u+w $(distdir) - mkdir $(distdir)/_build $(distdir)/_inst + mkdir $(distdir)/_build $(distdir)/_build/sub $(distdir)/_inst ## Undo the write access. chmod a-w $(distdir) ## With GNU make, the following command will be executed even with make -n, @@ -451,8 +451,12 @@ distcheck: dist ## Parallel BSD make may not start a new shell for each command in a recipe, ## so be sure to 'cd' back to the original directory after this. am__cwd=`pwd` \ - $(am__cd) $(distdir)/_build \ - ../configure \ +## If we merely used '$(distdir)/_build' here, make
bug#18286: [PATCH 1/2] tests: expose automake bug#18286 distcheck fails to detect missing files
* t/distcheck-pr18286.sh: New test, still XFAILing. * t/list-of-tests.mk: Add it. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/distcheck-pr18286.sh | 62 ++ t/list-of-tests.mk | 2 ++ 2 files changed, 64 insertions(+) create mode 100644 t/distcheck-pr18286.sh diff --git a/t/distcheck-pr18286.sh b/t/distcheck-pr18286.sh new file mode 100644 index 000..b107735 --- /dev/null +++ b/t/distcheck-pr18286.sh @@ -0,0 +1,62 @@ +#! /bin/sh +# Copyright (C) 2014 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/. + +# Ensure make distcheck detects all missing files, without getting +# confused by the fact that they exists in the original source tree +# from which make distcheck is run. See automake bug#18286. + +. test-init.sh + +echo AC_OUTPUT configure.ac + +cat Makefile.am 'END' +$(srcdir)/test_data.am: $(srcdir)/test_data.txt $(srcdir)/gen-testdata.sh + cd $(srcdir) $(SHELL) gen-testdata.sh test_data.txt test_data.am + +include $(srcdir)/test_data.am + +check-local: + is $(testdata) == foo bar +END + +cat test_data.txt 'END' +foo +bar +END + + +cat gen-testdata.sh 'END' +#!/bin/sh +printf 'testdata = \\\n' +sed 's/$/ \\/' +echo '$(empty_string)' +END +chmod a+x gen-testdata.sh + +$sleep +./gen-testdata.sh test_data.txt test_data.am + +$ACLOCAL +$AUTOCONF +$AUTOMAKE -a + +./configure + +$MAKE check + +run_make -e FAIL -M distcheck + +: diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk index c07eb72..ad96326 100644 --- a/t/list-of-tests.mk +++ b/t/list-of-tests.mk @@ -31,6 +31,7 @@ t/pm/Version3.pl XFAIL_TESTS = \ t/all.sh \ t/cond17.sh \ +t/distcheck-pr18286.sh \ t/gcj6.sh \ t/override-conditional-2.sh \ t/override-conditional-pr13940.sh \ @@ -427,6 +428,7 @@ t/distcheck-no-prefix-or-srcdir-override.sh \ t/distcheck-override-infodir.sh \ t/distcheck-pr9579.sh \ t/distcheck-pr10470.sh \ +t/distcheck-pr18286.sh \ t/dmalloc.sh \ t/doc-parsing-buglets-colneq-subst.sh \ t/doc-parsing-buglets-tabs.sh \ -- 2.1.3
bug#18440: libexec_LIBRARIES not allowed
tags 18440 notabug close 18440 thanks On 09/10/2014 10:49 AM, Ralf Corsepius wrote: On 09/10/2014 03:24 AM, Dan Nicolaescu wrote: Trying to add a target with libexec_LIBRARIES results in an error: error: 'libexecdir' is not a legitimate directory for 'LIBRARIES' But it looks like having libraries in libexec is something already in use by a few things. On a Fedora 20 machine: $ find /libexec -name \*.so /usr/libexec/p7zip/7z.so /usr/libexec/coreutils/libstdbuf.so /usr/libexec/sudo/sudo_noexec.so /usr/libexec/sudo/sudoers.so /usr/libexec/sudo/group_file.so /usr/libexec/sudo/system_group.so /usr/libexec/systemtap/libHelperSDT_amd64.so /usr/libexec/gcc/x86_64-redhat-linux/4.8.3/liblto_plugin.so /usr/libexec/deja-dup/tools/libduplicity.so Shouldn't automake support installing libraries in libexec? No. libexecdir is supposed to take binaries only. IMO, these listed above are packaging bugs. Ralf assessment is correct. I'm closing this bug as Working as Intended. Thanks, Stefano
bug#17908: [PATCH] dist: ordering of files in DIST_COMMON is deterministic now
It had likely stopped being deterministic due to the new perl behavior
of having non-deterministic order of numerating hash keys:
http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Hash_randomization
http://onionstand.blogspot.ie/2012/12/are-you-relying-on-hash-keys-being.html
See also similar commit v1.14-19-g52e6404.
Fixes automake bug http://debbugs.gnu.org/17908
* bin/automake.in (handle_dist): Sort @dist_common.
(print_autodist_files): Swap invocations of 'sort' and 'uniq', for
consistency with the new code in 'handle_dist' and to get rid of a
minor hack.
* NEWS: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS| 6 +-
bin/automake.in | 14 +++---
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/NEWS b/NEWS
index bdc9bb9..5d14c5e 100644
--- a/NEWS
+++ b/NEWS
@@ -116,6 +116,10 @@ New in 1.14.2:
risks causing Arg list too long for projects using automatic
dependency tracking and having a ton of source files (bug#18744).
+ - Automake tries to offer a more deterministic for generated Makefiles,
+in the face of the newly-introduced randomization for hash keys order
+in Perl 5.18.
+
New in 1.14.1:
@@ -131,7 +135,7 @@ New in 1.14.1:
was only relevant when the number of python files was high (which is
unusual in practice).
- - Automake try to offer a more reproducible output for warning messages,
+ - Automake try to offer a more deterministic output for warning messages,
in the face of the newly-introduced randomization for hash keys order
in Perl 5.18.
diff --git a/bin/automake.in b/bin/automake.in
index 283d1bb..7851454 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3714,10 +3714,13 @@ sub handle_dist ()
}
}
- # Files to distributed. Don't use -value_as_list_recursive
- # as it recursively expands '$(dist_pkgdata_DATA)' etc.
+ # Files to distributed. Don't use -value_as_list_recursive as it
+ # recursively expands '$(dist_pkgdata_DATA)' etc.
+ # Use 'sort' so that the expansion of $(DIST_COMMON) in the generated
+ # Makefile is deterministic, in face of m4 and/or perl randomizations
+ # (see automake bug#17908).
my @dist_common = split (' ', rvar ('DIST_COMMON')-variable_value);
- @dist_common = uniq (@dist_common);
+ @dist_common = uniq (sort @dist_common);
variable_delete 'DIST_COMMON';
define_pretty_variable ('DIST_COMMON', TRUE, INTERNAL, @dist_common);
@@ -7883,10 +7886,7 @@ sub generate_makefile
# Helper function for usage().
sub print_autodist_files
{
- # NOTE: we need to call our 'uniq' function with the leading ''
- # here, because otherwise perl complains that Unquoted string
- # 'uniq' may clash with future reserved word.
- my @lcomm = sort (uniq (@_));
+ my @lcomm = uniq (sort @_);
my @four;
format USAGE_FORMAT =
--
2.1.3
bug#18286: distcheck fails to detect missing files
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18286 On 08/18/2014 02:30 AM, Peter Johansson wrote: Hi, I have this snippet in my 'Makefile.am' include am/test_data.am $(srcdir)/am/test_data.am: $(srcdir)/test/data.txt $(srcdir)/am/test_data.am.in cd $(srcdir) $(SHELL) bootstrap am/test_data.am It first includes (at Automake time) a snippet, which is generated while bootstrapping. Now I forgot to include $(srcdir)/test/data.txt $(srcdir)/am/test_data.am.in in the distball, which caused the embarrassing make: *** No rule to make target `am/test_data.am.in', needed by `am/test_data.am'. Stop. The surprising thing is that distcheck does not detect this problem, but 'make distcheck' passes through without problem. This issue has been reported already in the past: http://lists.gnu.org/archive/html/automake/2006-09/msg8.html http://lists.gnu.org/archive/html/automake/2013-01/msg00049.html (BTW, sorry Nicola for missing your report and your fix for so long!) The reason for this is probably because while $(srcdir)/test/data.txt does not exist, make also looks in $(srcdir)/$(srcdir)/test/data.txt and that file exists as it is part of my development directory. If I change my Makefile.am to $(srcdir)/am/test_data.am: test/data.txt am/test_data.am.in cd $(srcdir) $(SHELL) bootstrap am/test_data.am 'make distcheck' will detect the problem, but I have this habit of type $(srcdir) for things that are supposed to be in $(srcdir). Is that a bad habit? It can sometimes lead to strange interactions, if not used consistently; see http://lists.gnu.org/archive/html/automake/2006-09/msg8.html and follow-up messages. But the issue you are experiencing is not due to that, but rather to a bug/limitation of the current 'distcheck' implementation. A fix could be to let distcheck not work in $(distdir) but instead create 'tmp_/$(distdir)', builddir 'tmp_/$(distdir)/build_', and installdir 'tmp_/$(distdir)/inst_' which would hide the development files from the distcheck. What do you think? Seems like a viable plan. In such a setup, relatively to $(builddir), $(srcdir) will be '..', while the developement copy of the source tree will be in '../..'; so the incomplete tarball should be diagnosed. Definitely a nice fix to have for Automake 1.15... Let's see if I can make it happen.
bug#11524: Declaring limited bug bankruptcy for Automake
tags 11524 wontfix tags 14079 wontfix tags 14760 wontfix tags 16447 wontfix tags 15681 wontfix close 11524 close 14079 close 14760 close 15681 close 16447 stop Due to my lack of time to dedicate to Automake, I'm declaring a limited bug bankruptcy on old bugs, in case they deal with testsuite-only glitches on exotic platforms, or with minor documentation glitches. Apologies to the original reporters. That said, if you have time, feel free to re-run the testsuite on the master branch and open new bugs for any failure you still see there. Also make sure to add as much detail as possible (e.g., the content of the relevant files for failed tests, rather than just the content of the .log files associated to the tests). Thanks, and apologies, Stefano
bug#19108: bad error messages in dist targets, automake 1.14.1
severity 19108 minor close 19108 thanks On 11/19/2014 05:40 PM, Aharon Robbins wrote: Hi. I'm trying to upgrade to automake 1.14.1, and I see this: @@ -993,10 +993,16 @@ dist-xz: distdir $(am__post_remove_distdir) dist-tarZ: distdir + @echo WARNING: Support for shar distribution archives is \ + deprecated. 2 + @echo WARNING: It will be removed altogether in Automake 2.0 2 tardir=$(distdir) $(am__tar) | compress -c $(distdir).tar.Z $(am__post_remove_distdir) dist-shar: distdir + @echo WARNING: Support for distribution archives compressed with \ + legacy program 'compress' is deprecated. 2 + @echo WARNING: It will be removed altogether in Automake 2.0 2 shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz $(am__post_remove_distdir) The error messages are associated with the wrong targets. I thought I reported this already... Thanks, Arnold Thank for the report. I've applied a fix that will appear in the next automake release. From 4410ae7f201a1e70da63b95680467223f77dffab Mon Sep 17 00:00:00 2001 Message-Id: 4410ae7f201a1e70da63b95680467223f77dffab.1418983893.git.stefano.lattar...@gmail.com From: Aharon Robbins arn...@skeeve.com Date: Fri, 19 Dec 2014 11:08:15 +0100 Subject: [PATCH] dist: adjust warning messages about shar and tarZ deprecation They were swapped. Reported in http://debbugs.gnu.org/19108. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- lib/am/distdir.am | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/am/distdir.am b/lib/am/distdir.am index a8ad63c..0c01960 100644 --- a/lib/am/distdir.am +++ b/lib/am/distdir.am @@ -339,8 +339,8 @@ dist-xz: distdir ?COMPRESS?DIST_ARCHIVES += $(distdir).tar.Z .PHONY: dist-tarZ dist-tarZ: distdir - @echo WARNING: Support for shar distribution archives is \ - deprecated. 2 + @echo WARNING: Support for distribution archives compressed with \ + legacy program 'compress' is deprecated. 2 @echo WARNING: It will be removed altogether in Automake 2.0 2 tardir=$(distdir) $(am__tar) | compress -c $(distdir).tar.Z $(am__post_remove_distdir) @@ -348,9 +348,9 @@ dist-tarZ: distdir ?SHAR?DIST_ARCHIVES += $(distdir).shar.gz .PHONY: dist-shar dist-shar: distdir - @echo WARNING: Support for distribution archives compressed with \ - legacy program 'compress' is deprecated. 2 @echo WARNING: It will be removed altogether in Automake 2.0 2 + @echo WARNING: Support for shar distribution archives is \ + deprecated. 2 shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz $(am__post_remove_distdir) -- 2.1.3
bug#19108: bad error messages in dist targets, automake 1.14.1
On 12/19/2014 11:37 AM, Gary V. Vaughan wrote: Hi Stefano, On 19 Dec 2014, at 10:12, Stefano Lattarini stefano.lattar...@gmail.com wrote: severity 19108 minor close 19108 thanks On 11/19/2014 05:40 PM, Aharon Robbins wrote: Hi. I'm trying to upgrade to automake 1.14.1, and I see this: @@ -993,10 +993,16 @@ dist-xz: distdir $(am__post_remove_distdir) dist-tarZ: distdir +@echo WARNING: Support for shar distribution archives is \ + deprecated. 2 +@echo WARNING: It will be removed altogether in Automake 2.0 2 tardir=$(distdir) $(am__tar) | compress -c $(distdir).tar.Z $(am__post_remove_distdir) dist-shar: distdir +@echo WARNING: Support for distribution archives compressed with \ + legacy program 'compress' is deprecated. 2 +@echo WARNING: It will be removed altogether in Automake 2.0 2 shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz $(am__post_remove_distdir) The error messages are associated with the wrong targets. I thought I reported this already... Thanks, Arnold Thank for the report. I've applied a fix that will appear in the next automake release. 0001-dist-adjust-warning-messages-about-shar-and-tarZ-dep.patch It looks like the warning content for those two targets are reversed to me... Cheers, Sure, in the diff that Aharon reported they were (which is why he opened the bug :-) My patch (attached to the message you replied to) fixes that.
bug#16841: Bug#738716: automake: Generates syntax error in configure script
tags 16841 + patch close 16841 thanks On 02/22/2014 08:40 AM, Eric Dorland wrote: * Hilko Bengen (ben...@debian.org) wrote: Source: automake-1.14 Version: 1:1.14.1-2 Severity: critical Tags: patch While trying to build a new version of nbdkit, I fonud that a freshly generated configure script contains a syntax error: , | $ curl -O http://libguestfs.org/download/nbdkit/nbdkit-1.1.4.tar.gz | [...] | $ tar xzf nbdkit-1.1.4.tar.gz | $ cd nbdkit-1.1.4/ | $ autoreconf | $ ./configure | [...] | checking for style of include used by make... GNU | checking whether make supports nested variables... yes | checking dependency style of gcc... gcc3 | ./configure: line 4820: syntax error near unexpected token `case' | ./configure: line 4820: `fi case `pwd` in' ` To me, this looks like a missing newline at the end of AM_INIT_AUTOMAKE in /usr/share/aclocal-1.14/init.m4. At least the attached patch fixes the problem for me. It looks like the problem is the dnl on your AM_INIT_AUTOMAKE line: AM_INIT_AUTOMAKE(foreign) dnl NB: Do not [quote] this parameter. That's suppressing the natural new line that would be there. But I think the patch is legitimate so forwarding it along. --- /usr/share/aclocal-1.14/init.m4.orig2014-02-12 09:45:22.883382346 +0100 +++ /usr/share/aclocal-1.14/init.m4 2014-02-12 09:45:40.758921507 +0100 @@ -164,7 +164,8 @@ END AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) fi -fi]) +fi +]) dnl Hook into '_AC_COMPILER_EXEEXT' early to learn its expansion. Do not dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further Agreed, we shouldn't have broken backward-compatibility for no good reason (and IIRC the removal of the trailing newline wasn't deliberated). Fixed with the attached patch. Thanks, Stefano From 69d9e8de6154916072900974d62f3b27ba9c664c Mon Sep 17 00:00:00 2001 Message-Id: 69d9e8de6154916072900974d62f3b27ba9c664c.1418988210.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 19 Dec 2014 11:44:12 +0100 Subject: [PATCH] AM_INIT_AUTOMAKE: make sure has a trailing newline after expansion This used to be the case until Automke 1.13, but we broke it in Automake 1.14 (see commit v1.13.1-71-gf78b0f0). This caused issues like http://debbugs.gnu.org/16841 * m4/init.m4 (AM_INIT_AUTOMAKE): Adjust. * t/aminit-trailing-dnl-comment-pr16841.sh: New test. * t/list-of-tests.mk: Add it. * NEWS, THANKS: Update. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- NEWS | 9 +++ THANKS | 1 + m4/init.m4 | 6 - t/aminit-trailing-dnl-comment-pr16841.sh | 44 t/list-of-tests.mk | 1 + 5 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 t/aminit-trailing-dnl-comment-pr16841.sh diff --git a/NEWS b/NEWS index 614eba6..626d295 100644 --- a/NEWS +++ b/NEWS @@ -104,6 +104,15 @@ +New in 1.14.2: + +* Bugs fixed: + + - The expansion of AM_INIT_AUTOMAKE ends once again with a trailing +newline (bug#16841). Regression introduced in Automake 1.14. + + + New in 1.14.1: * Bugs fixed: diff --git a/THANKS b/THANKS index 7f84850..9ace719 100644 --- a/THANKS +++ b/THANKS @@ -152,6 +152,7 @@ Harlan Stennharlan.st...@pfcs.com He Li tippa...@yahoo.com Henrik Frystyk Nielsen frys...@w3.org Hib Erish...@hiberis.nl +Hilko Bengenben...@debian.org Ian Lance Taylori...@cygnus.com Ignacy Gawedzki i...@lri.fr ÐлÑÑ Ð. ÐолÑбев g...@mo.msk.ru diff --git a/m4/init.m4 b/m4/init.m4 index 432ff20..d8350fe 100644 --- a/m4/init.m4 +++ b/m4/init.m4 @@ -164,7 +164,11 @@ to yes, and re-run configure. END AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) fi -fi]) +fi +dnl The trailing newline in this macro's definition is deliberate, for +dnl backward compatibility and to allow trailing 'dnl'-style comments +dnl after the AM_INIT_AUTOMAKE invocation. See automake bug#16841. +]) dnl Hook into '_AC_COMPILER_EXEEXT' early to learn its expansion. Do not dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further diff --git a/t/aminit-trailing-dnl-comment-pr16841.sh b/t/aminit-trailing-dnl-comment-pr16841.sh new file mode 100644 index 000..0f47f16 --- /dev/null +++ b/t/aminit-trailing-dnl-comment-pr16841.sh @@ -0,0 +1,44 @@ +#! /bin/sh +# Copyright (C) 2014 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
bug#18075: AM_INIT_AUTOMAKE followed by comment
forcemerge 16841 18075 stop Reference: http://debbugs.gnu.org/18075 Hi Scott. Thanks for the report, and sorry for the awful delay. I've already solved this issue as part of http://debbugs.gnu.org/16841 The fix will appear in the next Automake version (hopefully to be released before the end of December). Regards, Stefano
bug#17354: distclean fails when source is relatively otherplace
tags 17354 wontfix
close 17354
stop
On 04/27/2014 01:48 AM, Jan Engelhardt wrote:
With automake-1.13.4 automake-1.14, when there is a _SOURCES =
../blah.c, make does not properly run because .deps is gone too early.
File set:
# Makefile.am
SUBDIRS = b
noinst_PROGRAMS = foo
# configure.ac
AC_INIT([a],[0])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_PROG_CC
AC_CONFIG_FILES([Makefile b/Makefile])
AC_OUTPUT
# foo.c
int main(void){return 0;}
# b/Makefile.am
noinst_PROGRAMS = bar
bar_SOURCES = ../foo.c
Observed:
01:43 wrgstfl:/dev/shm/testcase make distclean
Making distclean in b
make[1]: Entering directory `/dev/shm/testcase/b'
test -z bar || rm -f bar
rm -f *.o
rm -f ../*.o
rm -f *.tab.c
test -z || rm -f
test . = . || test -z || rm -f
rm -f ../.deps/.dirstamp
rm -f ../.dirstamp
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -rf ../.deps
rm -f Makefile
make[1]: Leaving directory `/dev/shm/testcase/b'
make[1]: Entering directory `/dev/shm/testcase'
Makefile:348: .deps/foo.Po: No such file or directory
make[1]: *** No rule to make target `.deps/foo.Po'. Stop.
make[1]: Leaving directory `/dev/shm/testcase'
make: *** [distclean-recursive] Error 1
Expected:
Don't fail.
Additional information:
The problem is also observable without using ..;
foo_SOURCES = b/foo.c, bar_SOURCES = foo.c
also yields the same issue that one .deps is gone before the Makefile of
another directory is executed.
I would suggest using non-recursive builds, that solves many issues
this kind by giving make a better and complete view of the project
and its interdependencies.
I *might* end up fixing this bug if I manage to rework the dependency
tracking code to use the '-include' directive (which will require
dropping support for all make implementations not supporting such
directive, but I think that would be a good trade-off), but I'm not
making any promise. You should keep in mind that non-recursive
builds are discouraged (except the very rare cases where the stuff
in a subdirectory is truly and completely independent from *all*
stuff in any other subdirectory), and we'll no longer actively work
on adding features or fixing bugs involving them.
Regards,
Stefano
bug#19020: flex support
retitle 19020 improve support for flex in C++ mode tags 19020 + moreinfo thanks Reference: http://debbugs.gnu.org/19020 On 11/11/2014 11:51 AM, brahim sahbi wrote: Hello, Hi, sorry for the delay. I am trying to use flex with these options AM_LFLAGS = --header-file=lang.h --yyclass=Lang --c++ My problem is that the file generated by lex is lex.yy.cc and not lex.yy.c. So this command in the generated Makefile: .lpp.cpp: $(AM_V_LEX)$(am__skiplex) $(SHELL) $(YLWRAP) $ $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE) turns my lang.lpp to lang.cppc I have looked in the ylwrap by launching it with $(SHELL) -x and had this printed ++ printf '%s\n' lex.yy.cc ++ sed 's|lex\.yy\.c|lang.cpp|g;' + to=lang.cppc Am I doing it worng or is this a bug? This is sadly a limitation, in that we must assume that the output generated by lex and flex when a '-o' option is not given is 'yy.lex.c' (this would not be needed if we could assume the '-o' option works, but that assumption is not portable enough yet). The --c++ option of flex seem to break this expectation of the ylwrap script. I *think* it can be worked around by explicitly adding -o lex.yy.c to your AM_LFLAGS. Can you verify that solves your problem? Thanks, Stefano
bug#18744: Problem with am__is_gnu_make: Arg list too long
On 12/19/2014 08:13 PM, Daniel Richard G. wrote: On Fri, 2014 Dec 19 18:12+0100, Stefano Lattarini wrote: tags 18744 + patch close 18744 stop Reference: http://debbugs.gnu.org/18744 Should be fixed by the attached patch. Thank you Stefano, just a few comment typos I noticed: * The code used to detect whether the currently used make is GNU make or not not * Probably should read no longer risks causing rather than risk * as those cause non-GNU implementations rather than that cause ... implmentations * We can't use $(MAKE_VERSION) here, as it is also defined rather than as it also * might cause the shell to die rather than might cause to die? --Daniel Thanks Daniel, I've applied all your suggested fixes before pushing.
bug#19311: regression: 1.14 may use ac_aux_dir before defined (again)
retitle 19311 AC_PROG_CC can force wrong $ac_aux_dir definition in automake 1.14
severity 19311 minor
thanks
On 12/08/2014 06:15 PM, Jan Engelhardt wrote:
When AC_SYSTEM_EXTENSIONS precedes AM_INIT_AUTOMAKE, it used to throw an
error - which has been fixed in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15981 .
I have here another instance of what appears to be a similar issue. This
one is also a regression (used to work in 1.13.4), and the regression is
still present in {automake 1.14.1 + patch from #15981}. The problem
originates in libmemcached/configure.ac, and I have produced the
following reduced testcase that exhibits the issue:
$ cat EOF configure.ac
AC_INIT([foo], [0])
AC_PROG_CC([cc gcc clang])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([1.11 subdir-objects foreign])
AC_OUTPUT([Makefile])
EOF
$ echo '' Makefile.am
$ md m4
$ autoreconf -fi
configure.ac:2: installing 'build-aux/compile'
configure.ac:5: installing 'build-aux/install-sh'
configure.ac:5: installing 'build-aux/missing'
$ ./configure
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
configure: error: cannot find install-sh, install.sh, or shtool in . ./..
./../..
With automake-1.13.4, configure would succeed through to the end
(config.status: creating Makefile).
This is due to the fact that automake actually rewrite AC_PROG_CC
in order to integrate it with the 'compile' script, and to do so, it
needs the $am_aux_dir variable to be defined. That in turns requires
AC_CONFIG_AUX_DIR to be called beforehand. If that macro isn't
called explicitly before the AC_PROG_CC invocation, then the code in
AM_AUX_DIR_EXPAND will force-expand it with its default behavior,
which is to have configure look into '.', '..' and '../..' for the
required auxiliary scripts, and bail out if they are not found.
Which is what is causing your issue.
The issue can be solved by moving the AC_CONFIG_AUX_DIR call before
the AC_PROG_CC call. Arguably, a more user-friendly behavior would
be to automake patch AC_CONFIG_AUX_DIR so that it fails hard and with
a clear error message if it gets invoked after AM_AUX_DIR_EXPAND has
been called (explicitly or implicitly). Patches welcome (either for
code or docs).
An even better solution *might* be to shuffle the expansion of
AC_CONFIG_AUX_DIR so that it goes immediately after the AC_INIT
explansion, but that requires more m4 magic than my rusty brain
can grasp at the momwnt; and in addition, I'm not sure whether
such a change could cause new backward incompatibilities (possibly
subtle ones). Looping in Eric,Blake explicitly, who, being the m4
maintainer and one of the main Autoconf devs, is probably the best
person to give feedback.
Thanks,
Stefano
bug#17327: Bug report
retitle 17327 Automake dying with internal error: global options already
processed
tags 17327 moreinfo
thanks
On 04/23/2014 08:18 PM, Gallagher James wrote:
OSX 10.9, automake 1.14, autoconf 2.69
autoreconf: running: automake --add-missing --copy --force-missing
automake: error: global options already processed
automake: Please contact bug-automake@gnu.org.
at /usr/local/share/automake-1.14/Automake/Channels.pm line 662, GEN0 line
109.
Automake::Channels::msg('automake', '', 'global options already
processed') called at /usr/local/share/automake-1.14/Automake/ChannelDefs.pm
line 212
Automake::ChannelDefs::prog_error('global options already processed')
called at /usr/local/share/automake-1.14/Automake/Options.pm line 421
Automake::Options::process_global_option_list('HASH(0x7fe0a2007cd8)')
called at /usr/local/bin/automake line 5331
Automake::scan_autoconf_traces('configure.ac') called at
/usr/local/bin/automake line 5431
Automake::scan_autoconf_files() called at /usr/local/bin/automake line
8259
autoreconf: automake failed with exit status: 29
[jimg:shrew$]
Here’s the Makefile.am in question:
ACLOCAL_AMFLAGS = -I conf
EXTRA_DIST =
# Edit here and in the hyrax-* targets
SUBDIRS = src/libdap src/bes src/modules
# These will be passed to all builds if
# configure gets --enable-developer
# Modify as needed...
if BUILD_HYRAX_DEVELOPER
developer_arg = --enable-developer CXXFLAGS=-g3 -O0 -W -Wall -Wcast-align
LDFLAGS=-g
else
developer_arg=
endif
prefix_arg = --prefix=$(prefix)
# olfs_version_arg = -DHYRAX_VERSION= -DOLFS_VERSION=
olfs_version_arg = -DHYRAX_VERSION=nightly_build
# We have two different sets of these Makefile variables for OSX and Linux.
# Doing this simplifes managing checkins and the like.
# Only use these if you need them and make sure to double check the values.
# If they are wrong, configure in the modules dir will fail and that means
# other parts of the build will fail too.
…
[ plain ‘make’ lines follow ]
--
James Gallagher
jgallagher at opendap.org
406.723.8663
Did you perhaps invoke AM_INIT_AUTOMAKE twice in your configure.ac?
bug#19311: [FYI] {minor} Expose automake bug#19311
AC_PROG_CC called before AC_CONFIG_AUX_DIR can silently force wrong $ac_aux_dir definition. * t/auxdir-pr19311.sh: New. * t/list-of-tests.mk: Add it as an XFAIL test. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/auxdir-pr19311.sh | 45 + t/list-of-tests.mk | 2 ++ 2 files changed, 47 insertions(+) create mode 100644 t/auxdir-pr19311.sh diff --git a/t/auxdir-pr19311.sh b/t/auxdir-pr19311.sh new file mode 100644 index 000..56c71a1 --- /dev/null +++ b/t/auxdir-pr19311.sh @@ -0,0 +1,45 @@ +#! /bin/sh +# Copyright (C) 2014 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/. + +# Automake bug#19311: AC_PROG_CC called before AC_CONFIG_AUX_DIR can +# silently force wrong $ac_aux_dir definition. + +am_create_testdir=empty +required=cc +. test-init.sh + +cat configure.ac END +AC_INIT([$me], [1.0]) +AC_PROG_CC +AC_CONFIG_AUX_DIR([build-aux]) +AM_INIT_AUTOMAKE +AC_OUTPUT([Makefile]) +END + +: Makefile.am + +mkdir build-aux + +$ACLOCAL +$AUTOMAKE -a +$AUTOCONF + +test -f build-aux/compile +test -f build-aux/install-sh + +./configure + +: diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk index e6ee856..8d458f5 100644 --- a/t/list-of-tests.mk +++ b/t/list-of-tests.mk @@ -30,6 +30,7 @@ t/pm/Version3.pl XFAIL_TESTS = \ t/all.sh \ +t/auxdir-pr19311.sh \ t/cond17.sh \ t/gcj6.sh \ t/override-conditional-2.sh \ @@ -185,6 +186,7 @@ t/auxdir-autodetect.sh \ t/auxdir-computed.tap \ t/auxdir-misplaced.sh \ t/auxdir-nonexistent.sh \ +t/auxdir-pr19311.sh \ t/auxdir-unportable.tap \ t/backcompat.sh \ t/backcompat2.sh \ -- 2.1.3
bug#17536: automake.texi typo fixes
severity 17536 minor close 17536 stop
bug#18998: Fails in make check automake
On 11/08/2014 05:29 PM, braga wrote: Dear automake staff I am trying to install automake 1.14 but I am facing two fails in make check. I have also tried sudo make check but nothing change. I attach the make check log Regards, Vittorio The failure in t/autohdr-subdir-pr12495 was to do the fact that we grepped error messages from make without taking into account possible localization of those messages. The issue is already fixed in the last Automake version (see bug#bug#15237). The failure in t/install-info-dir appear to be the same already reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14601, still unresolved :-(
bug#17315: errors in make check
On 04/22/2014 06:15 PM, Coury, Marc wrote: Hello, Hello, and thanks for the report. I just installed automake-1.13.4. I followed the installation instructions, ./configure;make;make install then do a make check. After a very long time it finished with a few errors and said that I should send the test-suite.log to you. I've looked at the failures, and they are due to the fact that you still have Texinfo 4.8, while, since Automake 1.13, the rules to build PDF and DVI output from Texinfo input require Texinfo 4.9 or later. Note that this would happen also with Automake 1.14. I'm closing this bug as working as intended. Best regards, Stefano
bug#13928: [PATCH] plans: enabling subdir-object by default is blocked on bug#13928
On 04/22/2014 09:11 AM, Bert Wesarg wrote: Stefano, may it be possible to disable the 'subdir-object is the default'-warning in the 1.14 release series than? We should have this warning only active when we are sure that this bug is resolved. I'd rather not take this step back, since the 'subdir-objects' option works correctly in most situations. The right thing to do would be to fix the bug once and for all. If somebody wants to give it a try, I will be happy to review any patch in that direction. Otherwise, I will try to make time to attempt a fix myself in the coming weeks, but be warned that it would likely entail dropping automatic dependency tracking support for all those make implementations that doesn't support an equivalent of GNU make -include directive. (FWIW, I actually believe that is the right way forward, but several people on this list have expressed their dislike toward such a change, so I will give them time to try a different approach themselves before plunging ahead). Regards, Stefano
bug#15981: [PATCH] init: ensure $ac_aux_dir is defined before being used
Since we use $ac_aux_dir to define $am_aux_dir, we need to ensure
the former has been initialized before we try to define the latter,
otherwise the definition:
am_aux_dir=`cd $ac_aux_dir pwd`
will set $am_aux_dir to $HOME, causing weird and unexpected
behaviours.
This change fixes automake bug#15981.
* m4/auxdir.m4: AC_REQUIRE expansion of 'AC_CONFIG_AUX_DIR_DEFAULT'.
Fix redundant comment and AC_PREREQ, add extra quoting around
'$ac_aux_dir'.
* t/auxdir-pr15981.sh: New test.
* t/auxdir-cc-pr15981.sh: Likewise.
* t/list-of-tests.mk (handwritten_TESTS): Add them.
* THANKS: Update.
* bin/automake.in: Fix a harmless typo in comments, that I happened
to notice while writing this patch.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
THANKS | 1 +
bin/automake.in| 2 +-
m4/auxdir.m4 | 7 +++
t/auxdir-cc-pr15981.sh | 57 ++
t/auxdir-pr15981.sh| 39 ++
t/list-of-tests.mk | 2 ++
6 files changed, 103 insertions(+), 5 deletions(-)
create mode 100644 t/auxdir-cc-pr15981.sh
create mode 100644 t/auxdir-pr15981.sh
diff --git a/THANKS b/THANKS
index 550b565..eef67c3 100644
--- a/THANKS
+++ b/THANKS
@@ -317,6 +317,7 @@ Per Oyvind Hvidsten p...@enter.vg
Peter Breitenlohner p...@mppmu.mpg.de
Peter Eisentrautpete...@gmx.net
Peter Gavin pga...@debaser.kicks-ass.org
+Peter Hutterer peter.hutte...@who-t.net
Peter Johansson troj...@gmail.com
Peter Mattisp...@scam.xcf.berkeley.edu
Peter Muir i...@yahoo.com
diff --git a/bin/automake.in b/bin/automake.in
index 996a9de..f9cc611 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -313,7 +313,7 @@ my $seen_ar = 0;
# Location of AC_REQUIRE_AUX_FILE calls, indexed by their argument.
my %required_aux_file = ();
-# Where AM_INIT_AUTOMAKE is called;
+# Where AM_INIT_AUTOMAKE is called.
my $seen_init_automake = 0;
# TRUE if we've seen AM_AUTOMAKE_VERSION.
diff --git a/m4/auxdir.m4 b/m4/auxdir.m4
index 1f8614d..93fc225 100644
--- a/m4/auxdir.m4
+++ b/m4/auxdir.m4
@@ -45,8 +45,7 @@
# configured tree to be moved without reconfiguration.
AC_DEFUN([AM_AUX_DIR_EXPAND],
-[dnl Rely on autoconf to set up CDPATH properly.
-AC_PREREQ([2.50])dnl
-# expand $ac_aux_dir to an absolute path
-am_aux_dir=`cd $ac_aux_dir pwd`
+[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
+# Expand $ac_aux_dir to an absolute path.
+am_aux_dir=`cd $ac_aux_dir pwd`
])
diff --git a/t/auxdir-cc-pr15981.sh b/t/auxdir-cc-pr15981.sh
new file mode 100644
index 000..74157cb
--- /dev/null
+++ b/t/auxdir-cc-pr15981.sh
@@ -0,0 +1,57 @@
+#! /bin/sh
+# Copyright (C) 2014 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/.
+
+# Test automake bug#15981: automake 1.14 may use $ac_aux_dir
+# before it is defined, leading to error messages such as:
+# /bin/sh: /home/david/missing: No such file or directory
+
+required=cc
+. test-init.sh
+
+cat configure.ac END
+AC_INIT([$me], [0.0])
+AC_USE_SYSTEM_EXTENSIONS
+AM_INIT_AUTOMAKE([1.11 foreign])
+AC_CONFIG_FILES([Makefile])
+AC_SUBST([MISSING])
+AC_OUTPUT
+test -n \${MISSING}
+END
+
+echo 'int main (void) { return 0; }' foo.c
+
+cat Makefile.am 'END'
+bin_PROGRAMS = foo
+
+# Without quotes around '--help' and with an empty $(MISSING), make might
+# strip the trailing '--', call Bash's 'help' builtin, and have this test
+# succeed spuriously. Yes, that has happened in practice :-(
+test:
+ $(MISSING) '--help'
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+./configure 2stderr || { cat stderr 2; exit 1; }
+cat stderr 2
+$FGREP missing stderr exit 1
+
+$MAKE all
+$MAKE test
+
+:
diff --git a/t/auxdir-pr15981.sh b/t/auxdir-pr15981.sh
new file mode 100644
index 000..f09d551
--- /dev/null
+++ b/t/auxdir-pr15981.sh
@@ -0,0 +1,39 @@
+#! /bin/sh
+# Copyright (C) 2014 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
bug#17076: [PATCH] tests: depcomp2: avoid spurious failure on OS/X
Hi Jim, sorry for the delay (but don't expect anything better in the future, sadly). On 03/23/2014 09:49 PM, Jim Meyering wrote: I happened to notice a test failure on OS/X 10.8.5, and it was trivial to fix. I'll push this to master in a week unless I hear otherwise. I already have a similar change locally, but I forgot to push it to master. Will do soon. Closing this bug.
bug#16858: Testsuite summary for GNU Automake 1.13
On 02/24/2014 12:58 AM, Weiller Ronfini wrote: Good evening, attached is the error that happened when I did the test with make test make and after . / Configure. I would not worry about testsuite failures in a older Automake version. I'm closing this bug report as obsolete; I will now take a look at your bug report about testsuite failures in the latest Automake version (1.14.1). Thanks, Stefano
bug#16860: Testsuite summary for GNU Automake 1.14.1
On 02/24/2014 02:07 AM, Weiller Ronfini wrote: Good night, follows in the Annex zipped with gzip, the log file in response to the errors that occurred in automake. Thanks for the report. It appears the only two failures are spurious, and likely due to some issue with your Java installation. I'm thus closing this bug. Feel free to reopen if you find proof that this is not a problem with your Java installation, but with Automake itself. Thanks, Stefano
bug#16714: make check failures
tags 16714 + moreinfo severity 16714 + minor stop On 02/10/2014 11:17 AM, Rachel Mant wrote: Hello, Attached is my test-log for automake 1.14.1 which sports an alarming number of failures despite having upgraded my system's m4 and autoconf just fine to their newest versions. It seems something went horribly wrong with your build. Can you reproduce the issue in a clean build? If yes, can you describe the exact step you took to get such a build? Thanks, Stefano
bug#16375: subdir-objects breaks build which specifies sources relative to $(top_srcdir)
[+cc 13...@debbugs.gnu.org] References: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16375 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15919 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15293 Known bugs sadly -- all duplicates of http://debbugs.gnu.org/13928 See also recent thread on the automake list (with sad updates regarding the current Automake development status): http://lists.gnu.org/archive/html/automake/2014-04/msg2.html Closing these bug as a duplicate. Feel free to continue the discussion in the http://debbugs.gnu.org/13928 thread. And if anyone manages to come up with a patch, I will certainly make time to review it. Thanks, and sorry for the lack of progress, Stefano
bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters
Hi Paul, thanks for the patch. Just one meta-nit: for issues this small, there is no need to open a new bug report just to send the patch. Simply send it to the automake-patches list instead. On 04/01/14 05:56, Paul Eggert wrote: * doc/automake.texi: Specify @documentencoding and @documentlanguage, to prevent encoding errors for parts of this input file that are UTF-8. This also causes the .info output to use curly quotes, which is easier to read though it does assume UTF-8 support. --- doc/automake.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/automake.texi b/doc/automake.texi index 6d90182..d9083a0 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -2,6 +2,8 @@ @c %**start of header @setfilename automake.info @settitle automake +@documentencoding UTF-8 +@documentlanguage en @setchapternewpage off @c %**end of header Looks good; please push (to the 'micro' branch) and close this bug report once you're done. Thanks, Stefano
bug#16291: Use of /bin/rm
On 12/30/2013 04:44 PM, Ludovic Courtès wrote: Stefano Lattarini stefano.lattar...@gmail.com skribis: On 12/29/2013 10:49 PM, Ludovic Courtès wrote: [...] However, in general, I think packages should not rely on hardcoded file names, and instead use AC_PATH_PROG or similar mechanisms to get the right file name. Not in this case. The test is a spy check that tries to determine whether either (1) the first 'rm' in PATH or (2) '/bin/rm' *if present* is deficient, in that it errors out when the -f option is specified and no non-option argument is passed. If /bin/rm does not exist, it can't be deficient, so the test correctly passes (I assume that happened in your setup, right? Yes. Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? What do you think? That would be a bad idea, because we would miss warning from systems where /bin/rm is deficient but the user has installed a better rm (maybe from GNU coreutils) earlier in PATH. If all you are seeing are few SKIP messages and no failure, I don't think there is any problem to fix; everything is working as intended. Yes, of course. However, I’m still wondering: do Automake-generated makefiles and Autoconf macros explicitly attempt to use /bin/rm in normal use? Re Automake: not that I'm aware of. Have you any proof this is not the case? Re Autoconf: that should be asked on the autoconf list. Why does /bin/rm matter in the first place? Thanks for your quick feedback, Ludo’. Regards, Stefano
bug#16291: Use of /bin/rm
On 12/30/2013 09:55 PM, Ludovic Courtès wrote: [MEGA-SNIP] No; I’m asking because the tests specifically refer to /bin/rm. What’s the reason? Copying from my first reply: Ludovic Courtès wrote: Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? What do you think? That would be a bad idea, because we would miss warning from systems where /bin/rm is deficient but the user has installed a better rm (maybe from GNU coreutils) earlier in PATH. To reiterate, we want to find out about deficiencies in the base system even if the user who is running the Automake testsuite has mitigated them by installing better tools earlier in his PATH. Regards, Stefano
bug#16302: 1.14.1: check-TESTS is not lazy enough
tags 16302 + patch
severity 16302 minor
stop
On 12/30/2013 03:48 PM, Akim Demaille wrote:
Hi all,
Hi Akim.
I have this piece of software with several APIs, organized in clear
layers. Building the whole package is costly, especially because of
the top-level layers (dozens of binaries), and the whole test suite
is even costlier (because it requires to build the whole set of binaries,
and then it runs all the tests, including the costly top-level tests).
So, « of course », when developing this piece of software, I seldom run
the full test-suite, and run selected bits. In particular I avoid
« make all », so, of course, I also avoid « make check » since it depends
on the former. Rather I use check-TESTS and deal with the dependencies
myself, like a grownup.
Alas, for some reason, while it works well to generate individual test logs,
but when generating (the partial) test-suite.log, « make all-am » is
invoked.
Please try to attached tarball. It features a lazy test suite with two
test scripts.
AM_TESTS_ENVIRONMENT = export PATH=$(abs_top_builddir):$PATH;
RECHECK_LOGS =
TESTS = fast slow
« slow » runs a binary built by the package, so
of course, its log depends on this binary:
slow.log: foo
but ‘fast’ depends on nothing, so to run it and only it, I have
this piece of syntactic sugar:
check-fast:
$(MAKE) $(AM_MAKEFLAGS) check-TESTS TESTS='fast'
As expected ‘make check’ is lazy. However, if I touch
fast and foo.c (the dependency of slow), then observe:
$ touch ~/src/gnu/test-suite/{foo.c,fast}
$ make check-fast
/usr/bin/make check-TESTS TESTS='fast'
PASS: fast
depbase=`echo foo.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\
ccache gcc-mp-4.8 -DPACKAGE_NAME=\test-suite\
-DPACKAGE_TARNAME=\test-suite\ -DPACKAGE_VERSION=\1.0\
-DPACKAGE_STRING=\test-suite\ 1.0\ -DPACKAGE_BUGREPORT=\\
-DPACKAGE_URL=\\ -DPACKAGE=\test-suite\ -DVERSION=\1.0\ -I.
-I/Users/akim/src/gnu/test-suite -DNDEBUG -isystem /opt/local/include -O3
-MT foo.o -MD -MP -MF $depbase.Tpo -c -o foo.o
/Users/akim/src/gnu/test-suite/foo.c \
mv -f $depbase.Tpo $depbase.Po
ccache gcc-mp-4.8 -O3 -L/opt/local/lib -o foo foo.o
Testsuite summary for test-suite 1.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
As you can see, « fast.log » was recreated appropriately, but then,
to build test-suite.log, something fires « all-am » (running make
with -d shows this very well). It appears to be due to this:
$(TEST_SUITE_LOG): $(TEST_LOGS)
@$(am__set_TESTS_bases); \
am__f_ok () { test -f $$1 test -r $$1; }; \
redo_bases=`for i in $$bases; do \
am__f_ok $$i.trs am__f_ok $$i.log || echo $$i; \
done`; \
if test -n $$redo_bases; then \
redo_logs=`for i in $$redo_bases; do echo $$i.log; done`; \
redo_results=`for i in $$redo_bases; do echo $$i.trs; done`; \
if $(am__make_dryrun); then :; else \
rm -f $$redo_logs rm -f $$redo_results || exit 1; \
fi; \
fi; \
if test -n $$am__remaking_logs; then \
echo fatal: making $(TEST_SUITE_LOG): possible infinite \
recursion detected 2; \
else \
am__remaking_logs=yes $(MAKE) $(AM_MAKEFLAGS) $$redo_logs; \
fi; \
in this last bit, « $$redo_logs » is empty, so, blam, a full cost
make all. What was the point of this piece of code?
See the '##'-style comments in lib/am/check.am for detailed explanations
(such comments are stripped from the generated Makefiles, as I'm sure
you know).
At first sight it seems that it should be guarder by ‘test -n $$redo_log’.
Indeed.
This is *really* costly, I’d be happy to have nice workarounds.
Or eve better, to fix the bug :-) See attached patch. Does it work
for you?
Thanks, and happy new year!
Thanks,
Stefano
From ad9804e1b825ddb304bfaf62b7108f2b6e08dc81 Mon Sep 17 00:00:00 2001
Message-Id: ad9804e1b825ddb304bfaf62b7108f2b6e08dc81.1388444976.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Mon, 30 Dec 2013 23:21:03 +0100
Subject: [PATCH] parallel-tests: avoid possible implicit make all in
test-suite.log rule
This change fixes automake bug#16302.
* lib/am/check.am ($(TEST_SUITE_LOG)): Avoid running make $redo_logs
when $redo_logs expands to empty, since in that case we are actually
ending up invoking a full make all. That shouldn't be required, and
can cause slowdowns for people implementing their extra laziness
wrappers around check-TESTS (automake bug#16302).
* NEWS: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS| 4
lib/am/check.am | 4 +++-
2 files changed, 7
bug#16291: Use of /bin/rm
tags 16291 notabug close 16291 stop On 12/29/2013 10:49 PM, Ludovic Courtès wrote: Hello! While upgrading the GNU system to Automake 1.14.1, I noticed that a few tests emit warnings like this: SKIPs are not warning, just informative messages explaining why some tests couldn't be run. --8---cut here---start-8--- SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found PASS: t/spy-rm.tap 2 - rm -f SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found PASS: t/spy-rm.tap 4 - rm -rf SKIP: t/spy-rm.tap 5 # SKIP /bin/rm not found PASS: t/spy-rm.tap 6 - rm -fr --8---cut here---end---8--- There’s no /bin/rm in Guix build environments, hence the message (in fact, there’s no /bin at all.) This is not a problem, since our test is smart enough to skip the checks that would require the non-existent /bin/rm program. However, in general, I think packages should not rely on hardcoded file names, and instead use AC_PATH_PROG or similar mechanisms to get the right file name. Not in this case. The test is a spy check that tries to determine whether either (1) the first 'rm' in PATH or (2) '/bin/rm' *if present* is deficient, in that it errors out when the -f option is specified and no non-option argument is passed. If /bin/rm does not exist, it can't be deficient, so the test correctly passes (I assume that happened in your setup, right? If not, that would be a bug, and you'd be justified to reopen this report). Would it be possible to change these tests to use ‘rm’ instead of /bin/rm? What do you think? That would be a bad idea, because we would miss warning from systems where /bin/rm is deficient but the user has installed a better rm (maybe from GNU coreutils) earlier in PATH. If all you are seeing are few SKIP messages and no failure, I don't think there is any problem to fix; everything is working as intended. Thanks, Stefano
bug#15949: Apparently out-of-date warning
On 12/27/2013 09:36 PM, Reuben Thomas wrote: On 26 December 2013 15:39, Stefano Lattarini stefano.lattar...@gmail.comwrote: But AM_PROG_AR truly does not define $RANLIB itself. Perhaps you are using libtool and calling AC_PROG_LIBTOOL or LT_INIT? Probably. So, how about changing the sentence from should to may need, I'd rather leave the wording as it is; the may need is IMHO confusing, and I don't want to commit ourselves to specify in which exact situation AC_PROG_RANLIB is required and when it can be dispensed with. Since specifying AC_PROG_RANLIB even when not strictly needed turns out to be basically a no-op and not to cause any problem, I'd leave sleeping dogs lie, and change nothing. or is there some reason why AM_PROG_AR cannot AC_REQUIRE ranlib so that the sentence can be deleted and no action is necessary? AM_PROG_AR is only required for people interested in having their package buildable with Microsoft tools; so we can't expect all packages to use it, and we'd still need to mandate the use AC_PROG_RANLIB for all packages not using AM_PROG_AR. At which point, it's easier to leave documentation and semantics as they are, IMHO. Regards, Stefano
bug#14410: (was: GNU Automake 1.13.2 released)
retitle 14410 Suggested Texinfo suffixes inconsistent with suggestions of Texinfo manual severity 14410 minor tags 14410 wontfix close 14410 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14410 Hello Stefano. Hi Antonio, sorry for the awful delay in replying. Thanks for the detailed announcement. One learns things reading it. :-) Stefano Lattarini wrote: - Use of Texinfo input files with '.txi' or '.texinfo' extensions is discouraged, and its use will raise warnings in the 'obsolete' category. You are advised to simply use the '.texi' extension instead. After reading this, I have noticed an inconsistency between the automake and texinfo manuals about what extension is preferred: [1]http://www.gnu.org/software/automake/manual/html_node/Texinfo.html Any Texinfo source file must end in the .texi, .txi, or .texinfo extension. We recommend .texi for new manuals. [2]http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Minimum.html By convention, the name of a Texinfo file ends with (in order of preference) one of the extensions .texinfo, .texi, .txi, or .tex. The longer extensions are preferred since they describe more clearly to a human reader the nature of the file. The shorter extensions are for operating systems that cannot handle long file names. Is there a reason to recommend a different extension that what texinfo itself recommends? Yes, two related reasons: - Almost all existing GNU packages use the '.texi' extension for the sources of their Texinfo manuals. - To simplify the implementation, in Automake-NG I had decided to only support one suffix for Texinfo sources; since most existing packages use the '.texi' suffix already, that is the one I settled for, removing support for '.txi' and '.texinfo'. For backward compatibility reasons I didn't remove support for these two suffixes in mainline Automake, but still, I marked them as discouraged, in order to make an hypothetical transition to Automake-NG easier. Regards, Stefano
bug#13317: automake fails make check
tags 13317 + wontfix moreinfo close 13317 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13317 Hi Ronald, sorry for the ridiculous delay. I'm going through some old logs, and stumbled on this old report of yours. It seems to me that most of the failures you reported seem due to some misconfiguration of your environment, e.g.: ar cru liblib.a x.o /usr/bin/ranlib: invalid option -- q cc -g -O2 -o LDADD LDADD.o lib/liblib.a ld: warning: ignoring file lib/liblib.a, file was built for \ archive which is not the architecture being linked (x86_64) Undefined symbols for architecture x86_64: _lib, referenced from: _main in LDADD.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status In addition, automake have seen several non trivial changes in the areas relevant to your report since you sent it here. I'm thus going to close this report to avoid keeping the bug tracker too cluttered. If you want to retry running the testsuite of the new Automake release of just few days ago (1.14.1), feel free to open a new bug to report any failure you incur into. Thanks, Stefano
bug#11155: when cross-compiling with LT_INIT([win32-dll]) wrappers are installed instead of real programs
tags 11155 notabug close 11155 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11155 This actually looks like a libtool bug rather than an Automake one. I suggest you bring up the issue on libtool's list. If it turns out this actually is an Automake-specific issue, feel free to reopen this bug. Thanks (and sorry for the shameful delay in replying), Stefano
bug#9088: [PATCH] Make clear the JAVA primary will no longer be developed, not even for bug fixes.
tags 8540 + wontfix
tags 8662 + wontfix
close 8540
close 8662
stop
References:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8662
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8540
The existing java support in Automake is (with the JAVA primary) is
botched and hardly usable, so I'd rather declare it frozen and spend
no more time on it. The right direction for a better Java support
in automake is likely to implement the proposed new JARS primary:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088
The attached patch enhances the manual to make it clear that the
JAVA primary support is to be considered frozen, and will not even
receive bug fixes.
Unfortunately, I will have no time to attempt that implementation
myself in the foreseeable future, but I sill hope someone else will
find the time and motivation to give it a shot.
Anyway, I'm closing the bugs referring to the old JAVA primary as
Will not fix, to try to reduce the clutter in the Automake bug
tracker.
Thanks,
Stefano
From 50a08a2bc300d600603cdb5b5756baf71b9b431a Mon Sep 17 00:00:00 2001
Message-Id: 50a08a2bc300d600603cdb5b5756baf71b9b431a.1388069253.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Thu, 26 Dec 2013 15:46:13 +0100
Subject: [PATCH] docs: make clear the JAVA primary is frozen
* doc/automake.texi: Here. The JAVA primary is broken in several ways,
and will no longer be developed, not even for bug fixes.
See also automake bugs #9088, #8662 and #8540.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
doc/automake.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/automake.texi b/doc/automake.texi
index 91b4a0a..6d90182 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7598,7 +7598,9 @@ native machine code; @pxref{Java Support with gcj}). Note however that
Future Automake releases will strive to provide a better and cleaner
interface, which however @emph{won't be backward-compatible}; the present
interface will probably be removed altogether some time after the
-introduction of the new interface (if that ever materializes).
+introduction of the new interface (if that ever materializes). In any
+case, the current @code{JAVA} primary features are frozen and will no
+longer be developed, not even to take bug fixes.
Any @file{.java} files listed in a @code{_JAVA} variable will be
compiled with @code{JAVAC} at build time. By default, @file{.java}
--
1.8.5.rc0.335.g7794a68
bug#15949: Apparently out-of-date warning
tags 15949 + notabug close 15949 thanks On 11/21/2013 11:05 PM, Reuben Thomas wrote: I am using automake 1.13.3. I noticed in the manual the following sentence in the section on building static libraries, which I do for my project with libgnu.a: You should call 'AC_PROG_RANLIB' from your 'configure.ac' to define 'RANLIB' (Automake will complain otherwise). I call AM_PROG_AR, and as far as I can see from the placement in my generated configure, that seems to be sufficient to define RANLIB; AC_PROG_RANLIB doesn't seem to be needed. At least, I get no errors, and the library is built. But AM_PROG_AR truly does not define $RANLIB itself. Perhaps you are using libtool and calling AC_PROG_LIBTOOL or LT_INIT? This would exaplain your situation, since those macros call AC_REQUIRE on AC_PROG_RANLIB (or define $RANLIB in a way similar to how AC_PROG_RANLIB does it, I don't remember the exact details now). Can this sentence therefore be removed from the manual? I checked, and it is still present in current git. Give the above, I'd rather leave the sentence there :-) Closing this bug. Regards, Stefano
bug#14014: GNU Automake 1.13.1 testsuite FAIL: 1 on 3.2.0-4-powerpc64
severity 14014 minor close 14014 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14014 I'm closing this bug, since the spuriously failing test case (tap-realtime.sh) has been removed from the Automake testsuite already, as too brittle. Thanks, Stefano
bug#11377: configure.am - fails to remove configure before attempting replacement
tags 11377 + wontfix close 11377 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11377 No more activity on this wishlist and controversial bug for an year and a half. I'm thus closing it to reduce the clutter in our bug tracker. Regards, Stefano
bug#13314: GNU Automake 1.12.6 Testsuite FAIL: 2 on Solaris 10
tags 13314 + wontfix close 13314 thanks Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13314 As part of an effort to reduce clutter in our bug tracker, I'm closing this bug as obsolete, since we have results of testsuite runs for later automake releases (13.x and 14.x) on Solaris 10 already; e.g., see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15256). Regards, Stefano
bug#15521: two minor testsuite failures in Automake 1.14
tags 15521 + wontfix close 15521 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15521 No reply after two months from our feedback request, so I'm closing this bug to reduce the cluttering of our bug tracker. Regards, Stefano
bug#15720: 1 failure in testsuite of GNU Automake 1.14
severity 15720 minor close 15720 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15720 See also: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14014 I'm closing this bug, since the spuriously failing test case (tap-realtime.sh) has been removed from the Automake testsuite already, as too brittle. Thanks, Stefano
bug#7451: Better name for $(AM_V_at)?
tags 7451 wontfix close 7451 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7451 I no longer think it's worth spending any more time on this issue, at least not with the lack of manpower automake is suffering from at the moment. Closing to reduce the clutter in our bug tracker.
bug#7892: test failures induced by stale NFS files on Solaris
tags 7892 wontfix close 7892 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7892 According to the details in the report, this issue was probably due to a bug on Solaris NFS support. Also, this bug hasn't seen any activity in the past three years, and it's extremely unlikely it will see any in the foreseeable future. I'm thus closing it to reduce the clutter in our bug tracker. If anyone can reproduce this issue *and* has ideas for a fix can feel free to reopen it. Regard, Stefano
bug#14728: filenames starting with a dash confuse automake
tags 14728 wontfix close 14728 stop Stefano Lattarini wrote: Yes, but it might complicate or slow down the code, and I think it's not really worth spending time on it. I won't refuse a patch in this direction though, *if* it doesn't complicate or slow-down the code. Otherwise, I will close this bug as wontfix sometime in the nearish future. Since no new activity has been seen on this report in the last six months, I'm closing it as promised. Regards, Stefano
bug#15256: GNU Automake 1.14 : FAIL 6 on Solaris 10 Sparc v9
severity 15256 minor tags 15256 + moreinfo stop On 09/03/2013 03:47 PM, Dennis Clarke wrote: As per test report : Testsuite summary for GNU Automake 1.14 # TOTAL: 2874 # PASS: 2726 # SKIP: 101 # XFAIL: 41 # FAIL: 6 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to bug-automake@gnu.org gmake[2]: *** [test-suite.log] Error 1 gmake[2]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.10_sparcv9.001' gmake[1]: *** [check-TESTS] Error 2 gmake[1]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.10_sparcv9.001' gmake: *** [check-am] Error 2 I attach the test-suite.log file. The testsuite log shows these are the culprits : $ grep ^FAIL\:\ ./test-suite.log FAIL: t/instmany FAIL: t/instmany-mans FAIL: t/instmany-python About this failures: you should try the patch I posted at: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14891#38 and let me know if that fixes the failure of 't/instmany'. FAIL: t/yacc-cxx FAIL: t/yacc-d-cxx FAIL: t/yacc-mix-c-cxx Re these: I'm not sure if and when I'm going to look into them, sorry. It might help if you took a stab yourelf at figuring out what is going wrong. Regards, Stefano
bug#15258: Fortran tests in configure script seem questionable
tags 15258 + moreinfo
severity 15258 minro
thanks
Hi Dennis, sorry for the delay.
On 09/03/2013 04:36 PM, Dennis Clarke wrote:
I am going to try to build automake-13.4 on Solaris with the Oracle Solaris
12.3
dev tools and within configure I see that Fortran tests fail :
node002$ ./configure
checking whether /usr/local/bin/gmake supports nested variables... yes
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for a BSD-compatible install... lib/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... lib/install-sh -c -d
checking for gawk... gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether ln -s works... yes
checking for perl... /usr/local/bin/perl
checking whether /usr/local/bin/perl supports ithreads... no
checking for tex... tex
checking for yacc... yacc
checking for lex... lex
checking whether autoconf is installed... yes
checking whether autoconf works... yes
checking whether autoconf is recent enough... yes
checking whether ln works... yes
checking for grep that handles long lines and -e... /usr/xpg4/bin/grep
checking for egrep... /usr/xpg4/bin/grep -E
checking for fgrep... /usr/xpg4/bin/grep -F
configure: will now look for a sturdy POSIX shell, for our testsuite
checking for sh... /usr/xpg4/bin/sh
checking for sh5... no
checking for dash... no
checking for ash... no
checking for bash... /usr/local/bin/bash
checking for zsh... /usr/bin/zsh
checking for ksh... /usr/bin/ksh
checking for pdksh... no
checking whether /usr/local/bin/bash supports $(cmd)... yes
checking whether /usr/local/bin/bash supports $((expr))... yes
checking whether /usr/local/bin/bash supports ${#var}... yes
checking whether /usr/local/bin/bash supports ${var#glob} and ${var%glob}...
yes
checking whether /usr/local/bin/bash preserves exit traps with set -e... yes
checking whether /usr/local/bin/bash can define exit traps in a shell
function... yes
checking whether /usr/local/bin/bash corrupts stderr with set -x... no
checking whether /usr/local/bin/bash can return early from dot-sourced
files... yes
checking whether /usr/local/bin/bash supports alias named like shell
builtins... yes
checking whether /usr/local/bin/bash supports test -e... yes
configure: shell /usr/local/bin/bash is good enough, stop looking
configure: will use /usr/local/bin/bash as the testsuite shell
configure: will now look for generic compilers
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/solarisstudio12.3/bin/cc accepts -g... yes
checking for /opt/solarisstudio12.3/bin/cc option to accept ISO C89... none
needed
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... no
checking whether /opt/solarisstudio12.3/bin/CC accepts -g... yes
checking for xlf95... no
checking for f95... f95
checking whether the Fortran compiler works... no
configure: WARNING: Fortran compiler cannot create executables
configure: tests requiring the Fortran compiler will be skipped
checking for xlf... no
checking for f77... f77
checking whether the Fortran 77 compiler works... no
configure: WARNING: Fortran 77 compiler cannot create executables
configure: tests requiring the Fortran 77 compiler will be skipped
configure: will now look for GNU compilers
checking for gcc... no
checking for g++... no
checking for gpp... no
checking for gfortran... no
checking for g77... no
checking for gfortran... no
checking for gcj... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating t/wrap/aclocal-1.13
config.status: creating t/wrap/automake-1.13
node002$
This is highly suspect given that I have a full Fortran 77, 90 and 95
compiler in the Oracle software :
[SNIP]
To actually try to understand where the problem might be, I'd need the
content of the generated config.log file. Could you please send it over?
So perhaps the configure script is looking for GNU Fortran only?
No, on the contrary, the script is tweaked to prefer non-GNU compilers
where available, to enhance testsuite coverage.
The Fortran compilers provided, as well as everything else, are installed
in the bizarre location /opt/solarisstudio12.3/bin. For many many years
the defacto standard location for the vendor compilers in Solaris was
at /opt/SUNWspro and then someone at Sun or Oracle made
bug#15376: [FYI] {minor} install-sh: a slightly better diagnostic, and tests enhancements
* lib/install-sh: When called with no non-option arguments and the '-t'
option with an argument that is not an existing directory, have the
diagnostic output complain about the lack of required arguments rather
than about the bad argument passed to '-t'.
* t/install-sh-unittests.sh: Enhance to also check diagnostic printed
in cases of expected failure.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
lib/install-sh| 18 +-
t/install-sh-unittests.sh | 38 ++
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/lib/install-sh b/lib/install-sh
index d8de87f..0b0fdcb 100755
--- a/lib/install-sh
+++ b/lib/install-sh
@@ -193,15 +193,6 @@ if test $# -ne 0 test -z $dir_arg$dst_arg; then
done
fi
-if test -z $dir_arg; then
- if test $# -gt 1 || test $is_target_a_directory = always; then
-if test ! -d $dst_arg; then
- echo $0: $dst_arg: Is not a directory. 2
- exit 1
-fi
- fi
-fi
-
if test $# -eq 0; then
if test -z $dir_arg; then
echo $0: no input file specified. 2
@@ -213,6 +204,15 @@ if test $# -eq 0; then
fi
if test -z $dir_arg; then
+ if test $# -gt 1 || test $is_target_a_directory = always; then
+if test ! -d $dst_arg; then
+ echo $0: $dst_arg: Is not a directory. 2
+ exit 1
+fi
+ fi
+fi
+
+if test -z $dir_arg; then
do_exit='(exit $ret); exit $ret'
trap ret=129; $do_exit 1
trap ret=130; $do_exit 2
diff --git a/t/install-sh-unittests.sh b/t/install-sh-unittests.sh
index 1b85c9c..dff0c51 100644
--- a/t/install-sh-unittests.sh
+++ b/t/install-sh-unittests.sh
@@ -19,23 +19,37 @@
am_create_testdir=empty
. test-init.sh
+install_sh_fail ()
+{
+ err_rx=$1; shift
+ ./install-sh ${1+$@} 2stderr { cat stderr 2; exit 1; }
+ cat stderr 2
+ $EGREP install-sh:.* $err_rx stderr || exit 1
+}
+
get_shell_script install-sh
# Basic errors.
-./install-sh exit 1
-./install-sh -m 644 dest exit 1
+install_sh_fail 'no input file specified'
+install_sh_fail 'no input file specified' dest
+install_sh_fail 'no input file specified' -m 644 dest
+install_sh_fail 'no input file specified' -c -t dest
# Incorrect usages.
: bar
: baz
: qux
-./install-sh -d -t foo exit 1
-./install-sh -d -t foo bar exit 1
-./install-sh -t foo bar exit 1
-./install-sh bar baz foo exit 1
+install_sh_fail 'target directory not allowed when installing a directory' \
+-d -t foo
+install_sh_fail 'target directory not allowed when installing a directory' \
+-d -t foo bar
+install_sh_fail 'foo: [iI]s not a directory' -t foo bar
+install_sh_fail 'foo: [iI]s not a directory' bar baz foo
mkdir foo
-./install-sh -d -t foo exit 1
-./install-sh -d -t foo bar exit 1
+install_sh_fail 'target directory not allowed when installing a directory' \
+-d -t foo
+install_sh_fail 'target directory not allowed when installing a directory' \
+-d -t foo bar
rmdir foo
rm -f bar baz qux
@@ -96,8 +110,8 @@ test -f d4/z
./install-sh -T x d3/y
test -f x
test -f d3/y
-./install-sh -T x d3 exit 1
-./install-sh -T x d4// exit 1
+install_sh_fail 'd3: [iI]s a directory' -T x d3
+install_sh_fail 'd4(//)?: [iI]s a directory' -T x d4//
# Ensure that install-sh works with names that include spaces.
touch 'a b'
@@ -108,8 +122,8 @@ test -f 'a b'
# Ensure we do not run into 'test' operator precedence bugs with Tru64 sh.
for c in = '(' ')' '!'; do
- ./install-sh $c 2stderr { cat stderr 2; exit 1; }
- cat stderr 2
+ install_sh_fail 'no input file specified' $c
+ test -f stderr # sanity check
grep 'test: ' stderr exit 1
# Skip tests if the file system is not capable.
mkdir ./$c || continue
--
1.8.5.rc0.335.g7794a68
bug#11814: The test logs lost their title
tags 11814 +patch
close 11814
stop
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11814
Rather than adding yet another option, I've decided to simply enhance
the test-driver script to *append* the result and exit status of any
test it runs after the logged output of that test. This is implemented
by the attached patch. The change will appear in Automake 1.15 (since
I'm not sure it's 100% safe for a micro release),
Thanks, and sorry for the shameful delay,
Stefano
From 329cbe0ab70f1e7ee3d2f7ae00b5997d7e0bcb55 Mon Sep 17 00:00:00 2001
Message-Id: 329cbe0ab70f1e7ee3d2f7ae00b5997d7e0bcb55.1387918496.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 24 Dec 2013 17:45:18 +0100
Subject: [PATCH] testsuite harness: report test exit status in log file
The exit status of a test should be reported in the test logs, so
that one can see at a glance whether the test has succeeded or failed,
without having to look also into the corresponding .trs file.
This fixes automake bug#11814.
* lib/test-driver: Also report the test script exit status in the
test log (as the last line).
* t/check-exit-status-reported.sh: Test this new behaviour.
* t/list-of-tests.mk: Add the new test.
* t/ax/test-lib.sh( am_exit_trap): No longer log the test exit status;
this has been made redundant by the change to 'test-driver'. While at
it, fix an imperfect quoting.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
lib/test-driver | 13 +-
t/ax/test-lib.sh | 3 +-
t/list-of-tests.mk | 1 +
t/parallel-tests-exit-status-reported.sh | 68
4 files changed, 81 insertions(+), 4 deletions(-)
create mode 100644 t/parallel-tests-exit-status-reported.sh
diff --git a/lib/test-driver b/lib/test-driver
index d306056..110eec4 100755
--- a/lib/test-driver
+++ b/lib/test-driver
@@ -106,11 +106,14 @@ trap st=143; $do_exit 15
# Test script is run here.
$@ $log_file 21
estatus=$?
+
if test $enable_hard_errors = no test $estatus -eq 99; then
- estatus=1
+ tweaked_estatus=1
+else
+ tweaked_estatus=$estatus
fi
-case $estatus:$expect_failure in
+case $tweaked_estatus:$expect_failure in
0:yes) col=$red res=XPASS recheck=yes gcopy=yes;;
0:*) col=$grn res=PASS recheck=no gcopy=no;;
77:*) col=$blu res=SKIP recheck=no gcopy=yes;;
@@ -119,6 +122,12 @@ case $estatus:$expect_failure in
*:*) col=$red res=FAIL recheck=yes gcopy=yes;;
esac
+# Report the test outcome and exit status in the logs, so that one can
+# know whether the test passed or failed simply by looking at the '.log'
+# file, without the need of also peaking into the corresponding '.trs'
+# file (automake bug#11814).
+echo $res $test_name (exit status: $estatus) $log_file
+
# Report outcome to console.
echo ${col}${res}${std}: $test_name
diff --git a/t/ax/test-lib.sh b/t/ax/test-lib.sh
index aa015d6..b8c7253 100644
--- a/t/ax/test-lib.sh
+++ b/t/ax/test-lib.sh
@@ -254,7 +254,7 @@ am_exit_trap ()
# behaviour, while from time to time useful to developers, is not
# meant to be enabled by default, as it could cause spurious failures
# in the wild. Thus it will be enabled only when the variable
-# am_explicit_skips is set to a true value.
+# 'am_explicit_skips' is set to a true value.
case $am_explicit_skips in
[yY]|[yY]es|1)
if test $exit_status -eq 77 test $am__test_skipped != yes; then
@@ -266,7 +266,6 @@ am_exit_trap ()
fi
am_keeping_testdirs || rm_rf_ $am_test_subdir
set +x
- echo $me: exit $exit_status
# Spurious escaping to ensure we do not call our exit alias.
\exit $exit_status
}
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 462497e..ba65789 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -765,6 +765,7 @@ t/parallel-tests-basics.sh \
t/parallel-tests-concurrency.sh \
t/parallel-tests-concurrency-2.sh \
t/parallel-tests-empty.sh \
+t/parallel-tests-exit-status-reported.sh \
t/parallel-tests-generated-and-distributed.sh \
t/parallel-tests-recheck.sh \
t/parallel-tests-trailing-whitespace.sh \
diff --git a/t/parallel-tests-exit-status-reported.sh b/t/parallel-tests-exit-status-reported.sh
new file mode 100644
index 000..d40f1f5
--- /dev/null
+++ b/t/parallel-tests-exit-status-reported.sh
@@ -0,0 +1,68 @@
+#! /bin/sh
+# Copyright (C) 2013 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
bug#14601: Check failed, why?
tags 14601 + moreinfo
severity 14601 minor
stop
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14601
Hi Elio, thanks for the report and sorry for the awful delay.
I've fixed two of the failures you reported:
* t/autohdr-subdir-pr12495.sh
This failure was due to localization issues in make error messages;
it has already been fixed as part of bug#15237.
* t/t/tap-realtime.sh
This I can reproduce when mawk is used as the awk implementation
invoked by the tap-driver.sh script. Still this is a spurious
failure, because when I force mawk to be used by Automake's own
test suite, the driver correctly starts printing partial results
from TAP tests way before the tests have completed their execution
-- a failure to do so is exactly the issue this test is supposed
to spot. I'm now convinced this test is too brittle, and not
worth having, I've removed it with the first attached patch.
For the failure of install-info-dir.sh, however, I'm a bit at a
loss. For the moment, I've tweaked the tests to make it output
more information that can be useful for debugging (see the second
attached patch). Could you please re-run the test with these
tweaks, and get back to us with the complete output?
Thanks,
Stefano
From 9d9aa6d158d85c1c95aed63fd5633977f29d668f Mon Sep 17 00:00:00 2001
Message-Id: 9d9aa6d158d85c1c95aed63fd5633977f29d668f.1387825350.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Mon, 23 Dec 2013 19:12:09 +0100
Subject: [PATCH 1/2] tests: remove too-brittle test tap-realtime.sh
* t/tap-realtime.sh: Delete. It has always been brittle, but now
it's also causing spurious failures when mawk is used as the awk
implementation in tap-driver.sh (see bug#14601).
* t/list-of-tests.mk: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/list-of-tests.mk | 1 -
t/tap-realtime.sh | 127 -
2 files changed, 128 deletions(-)
delete mode 100644 t/tap-realtime.sh
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 75f303a..462497e 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1149,7 +1149,6 @@ t/tap-planskip-whitespace.sh \
t/tap-planskip-badexit.sh \
t/tap-planskip-bailout.sh \
t/tap-planskip-later-errors.sh \
-t/tap-realtime.sh \
t/tap-test-number-0.sh \
t/tap-recheck-logs.sh \
t/tap-result-comment.sh \
diff --git a/t/tap-realtime.sh b/t/tap-realtime.sh
deleted file mode 100644
index e9b2b0c..000
--- a/t/tap-realtime.sh
+++ /dev/null
@@ -1,127 +0,0 @@
-#! /bin/sh
-# Copyright (C) 2011-2013 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/.
-
-# TAP support:
-# - testsuite progress on console should happen mostly in real time;
-#i.e., it's not acceptable for the driver to wait the end of the
-#script to start displaying results from it.
-# FIXME: this test uses expect(1) to ensure line buffering from make and
-# children, and is pretty hacky and complex; is there a better way to
-# accomplish the checks done here?
-
-. test-init.sh
-
-cat expect-check 'END'
-eval spawn $env(SHELL) -c :
-expect eof
-END
-expect -f expect-check || {
-echo $me: failed to find a working expect program 2
-exit 77
-}
-rm -f expect-check
-
-# Unfortunately, some make implementations (among them, FreeBSD make,
-# NetBSD make, and Solaris Distributed make), when run in parallel mode,
-# serialize the output from their targets' recipes unconditionally. In
-# such a situation, there's no way the partial results of a TAP test can
-# be displayed until the test has terminated. And this is not something
-# our TAP driver script can work around; in fact, the driver *is* sending
-# out its output progressively and in sync with test execution -- it is
-# make that is stowing such output away instead of presenting it to the
-# user as soon as it gets it.
-if ! using_gmake; then
- case $MAKE in
-*\ -j*) skip_ doesn't work with non-GNU concurrent make;;
- esac
- # Prevent Sun Distributed Make from trying to run in parallel.
- DMAKE_MODE=serial; export DMAKE_MODE
-fi
-
-cat Makefile.am 'END'
-TESTS = all.test
-AM_COLOR_TESTS= no
-END
-
-. tap-setup.sh
-
-cat all.test 'END'
-#! /bin/sh
-echo 1..3
-
-# Creative quoting to placate maintainer-check.
-sleep=sleep 3
-
-# The awk+shell implementation of the TAP driver must read ahead of one
-# line
bug#16205: automake 1.14 chokes on file names with `='
tags 16205 wontfix severity 16205 wishlist close On 12/20/2013 10:20 AM, Sebastian Freundt wrote: Consider following Makefile.am: noinst_PROGRAMS = footool footool_SOURCES = foo=bar.c footool_CPPFLAGS = -DVERSION=4.0 processed with automake 1.14, autoconf 2.69, yields: /usr/share/automake-1.14/am/depend2.am: error: bad characters in variable name 'footool-foo' /usr/share/automake-1.14/am/depend2.am: warning: footool-foo multiply defined in condition TRUE ... /usr/share/automake-1.14/am/depend2.am: ... 'footool-foo' previously defined here autoreconf: automake failed with exit status: 1 Other automake versions are affected as well, at least automake 1.13.1 and automake 1.12.6 Also noteworthy the variant without CPPFLAGS seems to work: noinst_PROGRAMS = footool footool_SOURCES = foo=bar.c $ autoreconf -fi $ echo $? 0 Sorry, but I fear the real solution for this problem is: do not use problematic characters in filenames. I wouldn't reject a patch that fixes your problem (assuming it wouldn't complicate the code in any way), but I'm not going to attempt such a patch myself. So I'm closing this bug marking it as Will Not Fix; if you or anyone else manages to write a patch with the characteristics I've required, feel free to reopen the bug and sent the patch here. Thanks, Stefano
bug#16057: Non-parallel test suite API changes in 1.13
On 12/05/2013 10:49 PM, Eric Blake wrote: On 12/05/2013 03:28 PM, Stefano Lattarini wrote: tags 16057 notabug close 16057 stop On 12/05/2013 01:37 AM, Behdad Esfahbod wrote: Hi, Hello Behdad. Please advise how one is supposed to port their pre-1.13 test suite's TESTS_ENVIRONMENT to 1.13. Currently, in fontconfig and harfbuzz at least, we cannot find a solution that works both with 1.11 and 1.13, and we cannot require 1.13. Why not? 1.13 is almost one year old now... Believe it or not, some people still like to make their project work with out-of-the-box tools. I believe it, but I disagree with this approach, when the out-of-the-box tools are too outdated (But see below, the bit about documentation). In the case of libvirt, we strive to make our Makefile.am work on the software available in CentOS 5 (hello, patched automake 1.9) - and it is not a coincidence that this is also the oldest version still actively supported by gnulib. Just because newer releases are now a year old, and in spite of the fact that automake is fairly easy to self-install from a tarball, does NOT imply that everyone is willing to self-install. And I'm not willing to support such unwillingness, unless it's very easy do. Sorry. As I've already admitted, in retrospective, switching the default testsuite behaviour in a minor release have been a bad idea, since I broke the expectations of compatibility held by the users. But I can't change that mistake now now, and I believe the best way forward from the situation we are in is to encourage developers to update their tools. (And I believe we should do so also in the future -- but only by bumping major versions more frequently, not by breaking compatibility between minor versions). For good or for bad, there are enough developers that think of the autotools as magic black boxes that they are unwilling to use any version not shipped by their distro. I'm not willing to go to great lengths to support such attitude in the developers, sorry. So, anything that upstream automake can do to document HOW to write a Makefile.am that works on both modern AND ancient automake is appreciated. OTOH, I see no harm in documenting possible workarounds; we already do so so for other use cases we don't really support (e.g., keeping autotools generated files in a Git repository): it's easy to do, doesn't require us to maintain more code, and makes it clear to the user that it is not an encouraged setup and that maintaining it is his responsibility, not ours. So, patches welcome. You might be able to keep 1.11 compatibility with some more-or-less hacky workaround, but I'm not going to try to work out the details, because I believe that is the wrong approach. Automake is only required by developers, it's easy to install (and to install multiple versions in parallel, if different level of APIs compatibilities are needed), and only requires a very tiny amount of disk space. I'm closing this bug as works as intended. Sorry. I'm sorry to see this attitude; it is in the best interest as a developer tool to specifically document how to write code that still works with older versions. While it is okay to encourage the use of newer tools, we can't be so blind as to assume that people won't (or even can't) upgrade as fast as we'd like. We don't completely disagree in this at least (see above). Is AM_INIT_AUTOMAKE in 1.11 smart enough to handle m4 conditionals in the set of options requested? I think so (I'm not going to try it myself, but if somebody else does, I won't throw away the insight he gets ;-) And if so, can that be coupled with the use of m4_ifdef or some other m4 code to probe for a feature that only exists in 1.13 or newer? If so, try something along the lines of: AM_INIT_AUTOMAKE([1.11.1 gnits ...]m4_ifdef([1.13-witness], [ serial-tests]) The problem with this might be if the 1.13-witness gets screwd up by distro-specific patches somehow. If you manage to avoid that, seems a reasonable workaround. Regards, Stefano
bug#14891: GNU Automake 1.14 FAIL: 5
tags 14891 wontfix severity 14891 minor close 14891 stop On 11/04/2013 11:08 PM, Stefano Lattarini wrote: tags 14891 + moreinfo stop On 07/17/2013 01:47 PM, Dennis Clarke wrote: So today we have a much older system but a very very stable one and a decent compiler in the form of the Sun Studio tools on Solaris. What I see is : . . . SKIP: t/depcomp-msvisualcpp.tap - Microsoft C compiler 'cl' not available SKIP: t/depcomp-cpp.tap - GNU C compiler unavailable SKIP: t/depcomp-gcc.tap - GNU C compiler unavailable parallel-tests-html: skipped test: no proper rst2html program found SKIP: contrib/t/parallel-tests-html.sh parallel-tests-html-recursive: skipped test: no proper rst2html program found SKIP: contrib/t/parallel-tests-html-recursive.sh PASS: contrib/t/help-multilib.sh multilib: skipped test: GNU C compiler unavailable SKIP: contrib/t/multilib.sh gmake[3]: Entering directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' Testsuite summary for GNU Automake 1.14 # TOTAL: 2722 # PASS: 2434 # SKIP: 244 # XFAIL: 39 # FAIL: 5 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to bug-automake@gnu.org gmake[2]: *** [test-suite.log] Error 1 gmake[2]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake[1]: *** [check-TESTS] Error 2 gmake[1]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake: *** [check-am] Error 2 okay .. not bad but can not be installed either. The tests that failed : [SNIP] FAIL: t/instmany.sh FAIL: t/instmany-mans.sh Please try whether the attached patch solves the failure for t/instmany.sh. If it does, I will turn it into a proper commit that also handle the other t/instmany* tests. Regards, Stefano No reply so far. Since the issues only affected an obsolete Solaris 8 system, I don't think it's worth spending more time on those. I'm thus closing this bug. Thanks, Stefano
bug#14891: GNU Automake 1.14 FAIL: 5
tags 14891 + moreinfo stop On 07/17/2013 01:47 PM, Dennis Clarke wrote: So today we have a much older system but a very very stable one and a decent compiler in the form of the Sun Studio tools on Solaris. What I see is : . . . SKIP: t/depcomp-msvisualcpp.tap - Microsoft C compiler 'cl' not available SKIP: t/depcomp-cpp.tap - GNU C compiler unavailable SKIP: t/depcomp-gcc.tap - GNU C compiler unavailable parallel-tests-html: skipped test: no proper rst2html program found SKIP: contrib/t/parallel-tests-html.sh parallel-tests-html-recursive: skipped test: no proper rst2html program found SKIP: contrib/t/parallel-tests-html-recursive.sh PASS: contrib/t/help-multilib.sh multilib: skipped test: GNU C compiler unavailable SKIP: contrib/t/multilib.sh gmake[3]: Entering directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' Testsuite summary for GNU Automake 1.14 # TOTAL: 2722 # PASS: 2434 # SKIP: 244 # XFAIL: 39 # FAIL: 5 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to bug-automake@gnu.org gmake[2]: *** [test-suite.log] Error 1 gmake[2]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake[1]: *** [check-TESTS] Error 2 gmake[1]: Leaving directory `/usr/local/build/automake-1.14_SunOS5.8_sparcv9.001' gmake: *** [check-am] Error 2 okay .. not bad but can not be installed either. The tests that failed : [SNIP] FAIL: t/instmany.sh FAIL: t/instmany-mans.sh Please try whether the attached patch solves the failure for t/instmany.sh. If it does, I will turn it into a proper commit that also handle the other t/instmany* tests. Regards, Stefano From 88e09c231280f39803dbb05583b51c6e04e41c17 Mon Sep 17 00:00:00 2001 Message-Id: 88e09c231280f39803dbb05583b51c6e04e41c17.1383606413.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Mon, 4 Nov 2013 23:01:27 + Subject: [PATCH] tests: fix spurious failure when install-sh is used (bug#14891) Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/instmany.sh | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/t/instmany.sh b/t/instmany.sh index 0a479cc..925527b 100644 --- a/t/instmany.sh +++ b/t/instmany.sh @@ -81,7 +81,15 @@ END chmod +x x-bin/'rm' x-bin/my-install cat setenv.in 'END' -orig_INSTALL='@INSTALL@'; export orig_INSTALL +# When the install-sh is selected, $INSTALL is defined as a relative +# path. Since we might chdir around, we have to rewrite it to be an +# absolute path. See autmake bug#14891. +orig_INSTALL='@INSTALL@' +case $orig_INSTALL in + /*) ;; + */*) orig_INSTALL=`pwd`/$orig_INSTALL +esac +export orig_INSTALL END cat configure.ac END -- 1.8.5.rc0.23.gaa27064
bug#14891: GNU Automake 1.14 FAIL: 5
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14891#26
On 10/30/2013 11:52 PM, Stefano Lattarini wrote:
Hi Dennis.
On 07/21/2013 05:23 PM, Stefano Lattarini wrote:
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14891
On 07/17/2013 01:47 PM, Dennis Clarke wrote:
FAIL: t/test-extensions.sh
Please try the patch below for this, and let me know if it
fixes this spurious failure.
Thanks,
Stefano
8 8 8 --- 8 8 8 8 8
From 9ac9b2ceef705596cdf77501ea2669f17d1f280e Mon Sep 17 00:00:00 2001
Message-Id:
9ac9b2ceef705596cdf77501ea2669f17d1f280e.1374423800.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 21 Jul 2013 17:15:38 +0100
Subject: [PATCH] tests: avoid use of intervals to capitalize letters
It was causing spurious failures with with Solaris 8 'tr'.
See automake bug#14891.
* t/test-extensions.sh: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/test-extensions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-extensions.sh b/t/test-extensions.sh
index 0700991..ca7c5ec 100644
--- a/t/test-extensions.sh
+++ b/t/test-extensions.sh
@@ -39,7 +39,7 @@ $AUTOMAKE -a
grep -i 'log' Makefile.in # For debugging.
for lc in $valid_extensions; do
- uc=$(echo $lc | tr '[a-z]' '[A-Z]')
+ uc=$(echo $lc | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ)
$FGREP \$(${uc}_LOG_COMPILER) Makefile.in
grep ^${uc}_LOG_COMPILE = Makefile.in
grep ^\.${lc}\.log: Makefile.in
Ping? Does this solve your problem with this test?
I pushed this patch. Please let me know if the issue persists.
Stefano
bug#14991: distcheck passes --prefix to configure before *DISTCHECK_CONFIGURE_FLAGS
On 10/31/2013 08:25 AM, Akim Demaille wrote: Hi Stefano! Le 30 oct. 2013 à 23:02, Stefano Lattarini stefano.lattar...@gmail.com a écrit : I've fixed the issue with the two attached patches, that will appear in Automake 1.14.1 (someday when I'll actually get around to release it ;-). I will wait some time before pushing the patches out, so a review is welcome. It looks fine, thanks! Pushed. Thanks, Stefano
bug#14891: [PATCH] automake: account for perl hash order randomization
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14891#20 On 07/23/2013 08:34 PM, Stefano Lattarini wrote: Hi Pavel. On 07/22/2013 05:39 PM, Pavel Raiskup wrote: These are not Solaris issues AFAIK, but are due to an incompatible change in perl 5.18. The patch below should take care of it. Can you confirm it works? FWIW, it fixed the testsuite problem for me (after change to perl 5.18). I also don't see any problem in your patch. Thanks for confirming. Will push once the other issues related to this report has been fixed as well. Well, I'd say we've waited too much already :-) Patch pushed. Thanks, and sorry for all the delays, Stefano
bug#15098: Acknowledgement (Automake Test Suite log attached)
tags 15098 notabug close 15098 stop Reference: http://debbugs.gnu.org/15098 Hi Lou, and sorry for the awful delay. On 08/15/2013 02:36 PM, Lou Picciano wrote: My error! With apologies, please find attached the output of make check Thanks for letting us know. So I understand the failure was due to an user error, and the testsuite now passes for you. I'm thus closing this bug report. If I've misunderstood and you are still experiencing problems, feel free to reopen. Best regards, Stefano
bug#14891: GNU Automake 1.14 FAIL: 5
Hi Dennis.
On 07/21/2013 05:23 PM, Stefano Lattarini wrote:
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14891
On 07/17/2013 01:47 PM, Dennis Clarke wrote:
FAIL: t/test-extensions.sh
Please try the patch below for this, and let me know if it
fixes this spurious failure.
Thanks,
Stefano
8 8 8 --- 8 8 8 8 8
From 9ac9b2ceef705596cdf77501ea2669f17d1f280e Mon Sep 17 00:00:00 2001
Message-Id:
9ac9b2ceef705596cdf77501ea2669f17d1f280e.1374423800.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 21 Jul 2013 17:15:38 +0100
Subject: [PATCH] tests: avoid use of intervals to capitalize letters
It was causing spurious failures with with Solaris 8 'tr'.
See automake bug#14891.
* t/test-extensions.sh: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/test-extensions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-extensions.sh b/t/test-extensions.sh
index 0700991..ca7c5ec 100644
--- a/t/test-extensions.sh
+++ b/t/test-extensions.sh
@@ -39,7 +39,7 @@ $AUTOMAKE -a
grep -i 'log' Makefile.in # For debugging.
for lc in $valid_extensions; do
- uc=$(echo $lc | tr '[a-z]' '[A-Z]')
+ uc=$(echo $lc | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ)
$FGREP \$(${uc}_LOG_COMPILER) Makefile.in
grep ^${uc}_LOG_COMPILE = Makefile.in
grep ^\.${lc}\.log: Makefile.in
Ping? Does this solve your problem with this test?
Stefano
bug#15237: Bug - teste-suíte.log
tags 15237 minor close 15237 stop Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15237 Thanks for the report, and sorry for the delay. This was a spurious failure, fixed by the attached patch. Regards, Stefano From 739337ae1cf2dd6c582180962c02afcddd421637 Mon Sep 17 00:00:00 2001 Message-Id: 739337ae1cf2dd6c582180962c02afcddd421637.1383091520.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Wed, 30 Oct 2013 00:04:51 + Subject: [PATCH] tests: fix spurious failure due to localization issues Fixes automake bug#15237. * t/autohdr-subdir-pr12495.sh: Ensure make is run in the C locale, so that we can expect error messages in English when grepping its output. * THANKS, NEWS: Update. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- NEWS| 2 +- THANKS | 1 + t/autohdr-subdir-pr12495.sh | 4 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 2d36e95..43640ed 100644 --- a/NEWS +++ b/NEWS @@ -118,7 +118,7 @@ New in 1.14.1: message on the most common invalid usages. - Several spurious failures/hangs in the testsuite (bugs #14706, #14707, -#14760 and #14911). +#14760, #14911, #15237). * Documentation fixes: diff --git a/THANKS b/THANKS index a229781..3adea7e 100644 --- a/THANKS +++ b/THANKS @@ -411,6 +411,7 @@ Vasyl Khalakbasiliom...@gmail.com Vincent Lefevre vinc...@vinc17.org Vladimir Serbinenko phco...@gmail.com Volker Boerchersvboerch...@tecon.de +Weiller Ronfini weillerronf...@yahoo.com.br Werner John j...@oswf.de Werner Koch w...@isil.d.shuttle.de Werner Lemberg w...@gnu.org diff --git a/t/autohdr-subdir-pr12495.sh b/t/autohdr-subdir-pr12495.sh index 7e26b46..dcb9620 100644 --- a/t/autohdr-subdir-pr12495.sh +++ b/t/autohdr-subdir-pr12495.sh @@ -63,6 +63,10 @@ $MAKE test -f a.h.in test -f a.h +# We might need to grep the output of GNU make for error messages. +LANG=C LANGUAGE=C LC_ALL=C +export LANG LANGUAGE LC_ALL + ocwd=$(pwd) for x in b c; do test $x = b || cd sub -- 1.8.3.1.605.g85318f5
bug#15181: t/dist-formats.tap: zip + unzip
severity 15181 minor
close 15181
stop
(Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15181)
Hi Andrea, thanks for the report and the patch, and
sorry for the awful delay.
On 08/24/2013 06:24 AM, Andrea Urbani wrote:
Good morning,
gzip, lzip, bzip2, tar, xz can compress and decompress.
zip is able just to compress. To decompress you need unzip.
During the tests of Automake 1.14, in particular t/dist-formats.tap, the
nogzip function called via
nogzip in ac and zip in ac
looks if zip is available and, if yes, tests the zip creation + unzip.
If in your system zip is installed but unzip no, you will have a FAIL like
the following:
/bin/sh: line 14: unzip: command not found
make: *** [distcheck] Error 127
+ tap_result_='not ok'
+ result_ 'not ok' -D '' -r '' -- 'ac=dist-zip,no-dist-gzip [distcheck]'
+ set +x
not ok 45 - ac=dist-zip,no-dist-gzip [distcheck]
FAIL: t/dist-formats.tap 45 - ac=dist-zip,no-dist-gzip [distcheck]
and so the final result of the make check operation will fail too.
In my opinion the unzip should be skipped if no unzip is available.
Good point. In fact, I've managed to reproduce your issue (by faking
a failing 'unzip' command).
== PATCH BEGIN
--- t/dist-formats.tap.orig 2013-06-19 11:29:50.0 +0200
+++ t/dist-formats.tap 2013-08-24 07:12:42.0 +0200
@@ -97,6 +97,33 @@
fatal_ have_compressor(): dead code reached
}
+have_decompressor ()
+{
+ test $# -eq 1 || fatal_ have_decompressor(): bad usage
+ case $1 in
+ zip)
+ # 2013-08-24 matfanjol
+ # gzip, lzip, bzip2, tar, xz can compress and decompress.
+ # zip is able just to compress. To decompress you need unzip.
+ # Here I check if unzip is available.
+ # I checked Oracle Solaris 11 and Fedora 19: unzip -v is
+ # OK, unzip --version is NOT ok.
+ if unzip -v /dev/null 2; then
+ return 0
+ else
+ return 1
+ fi
+ ;;
+ *)
+ # 2013-08-24 matfanjol
+ # gzip, lzip, bzip2, tar, xz can compress and decompress.
+ return 0
+ ;;
+ esac
+ fatal_ have_decompressor(): dead code reached
+}
+
+
all_compression_formats='gzip lzip xz bzip2 zip'
all_compressors=$(
@@ -165,6 +192,20 @@
fi
}
+command_ok_if_have_compressor_and_decompressor ()
+{
+ if have_compressor $compressor; then
+ if have_decompressor $compressor; then
+ command_ok_ $@
+ else
+ skip_ -r decompressor for '$compressor' not available $1
+ fi
+ else
+ skip_ -r '$compressor' not available $1
+ fi
+}
+
+
can_compress ()
{
test $# -eq 2 || fatal_ can_compress: bad number of arguments
@@ -276,8 +317,8 @@
command_ok_ $desc [autoconf] $AUTOCONF
command_ok_ $desc [configure] ./configure
command_ok_ $desc [ark-name] $MAKE check-ark-name
- command_ok_if_have_compressor $desc [distcheck] $MAKE distcheck
- command_ok_if_have_compressor $desc [ark-exists] $MAKE check-ark-exists
+ command_ok_if_have_compressor_and_decompressor $desc [distcheck] $MAKE
distcheck
+ command_ok_if_have_compressor_and_decompressor $desc [ark-exists] $MAKE
check-ark-exists
command_ok_ $desc [no .tar.gz] $MAKE check-no-tar-gz
unset desc
== PATCH END
Thanks for the patch (it's always appreciated to receive one with a
bug report!), but I've chose a slightly smaller and less invasive
change to fix the issue (see attached patch). With that, all the
checks involving either zip or unzip will be skipped on systems
lacking unzip (even if they have zip); this is less granular than
your approach, but this added coarseness is IMO worth the reduction
in complexity.
Bye
Andrea
matfanjol
http://matfanjol.users.sourceforge.net/
I'm marking this bug as solved.
Thanks again,
Stefano
From 07bd3e6d252fb513828d04d884147384229acf67 Mon Sep 17 00:00:00 2001
Message-Id: 07bd3e6d252fb513828d04d884147384229acf67.1383094328.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Wed, 30 Oct 2013 00:51:25 +
Subject: [PATCH] tests: fix spurious failure when zip is present but unzip is
not
Fixes automake bug#15181.
* t/dist-formats.tap (have_compressor): When checking that zip(1), also
check for unzip(1), otherwise make distcheck will be unable to extract
the zip tarball it creates, which will cause spurious failures. While
at it, reorganize the existing code a bit.
* THANKS, NEWS: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 2 +-
THANKS | 1 +
t/dist-formats.tap | 54 +-
3 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/NEWS b/NEWS
index 43640ed..5fc256b 100644
--- a/NEWS
+++ b/NEWS
@@ -118,7 +118,7 @@ New in 1.14.1:
message on the most common invalid usages.
- Several spurious failures/hangs in the testsuite (bugs #14706, #14707,
-#14760, #14911, #15237).
+#14760, #14911, #15181, #15237
bug#15518: rm test
tags 15518 wontfix close 15518 thanks On 09/30/2013 02:49 AM, Tim Rice wrote: Reporting as requested. checking for a BSD-compatible install... /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /opt/src/gnu/m4-1.4.17/build-aux/install-sh -c -d checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... no UX:rm: ERROR: Incorrect usage UX:rm: TO FIX: Usage: rm [-fiRr] file ... Oops! Your 'rm' program seems unable to run without file operands specified on the command line, even when the '-f' option is present. This is contrary [snip] configure: error: Your 'rm' program is bad, sorry. ^^^ Bad? I don't think so. Old? Sure. PATH=/usr/bin:/opt/bin:/usr/ccs/bin:/usr/ucb:/usr/gnu/bin:/usr/java/bin:/usr/local/bin:/homes/tim/bin/UnixWare config.guess says i686-unknown-sysv5UnixWare7.1.4 My suggestion: install GNU rm, or adjust your PATH in case you have already another better (errm, younger :-) 'rm' installed . Future versions of automake (ETA still undetermined) will require an 'rm' program that doesn't choke when invoked with the -f option and no arguments. Also, the next version of POSIX will mandate such a behaviour. For more information and background, see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10828 I'm closing the bug because the plan of requiring argumentless rm -f to just work remains in place; the request for a report that is issued by the script (and that prompted you to open this bug report) is more to allow us to have some gauge of how many systems we are going to affect with that change (yours is the first one so far), rather than to decide whether to go along with it. Thanks, Stefano
bug#15639: [GNU Autoconf 2.60] testsuite: 3 4 23 25 130 132 133 134 135 failed
tags 15639 notabug close 15639 stop On 10/18/2013 12:08 AM, Eric Blake wrote: On 10/17/2013 02:08 PM, Simone ETFerraz wrote: | Version 2.60. | Thanks for the report. However, this version is extremely old; more interesting would be tests against 2.69 or against autoconf.git (which reminds me, I need to set aside to release 2.70 soon). And in any case, this is not an automake issue. Closing.
bug#15114: Problem solved
tags 15114 notabug close 15114 thanks On 08/17/2013 09:09 PM, Raphael 'kena' Poss wrote: Please disregard my bug report. The issue was caused by a stray file named configure in the build directory (separate from source dir). I am still surprised that make dist strips the executable bit from the stray file, but at least this explains why the file in the distdir (and the archive) is truncated. Cheers Thanks for letting us know. I'm now closing this ticket. Regards, Stefano
bug#14891: [PATCH] automake: account for perl hash order randomization
Hi Pavel. On 07/22/2013 05:39 PM, Pavel Raiskup wrote: These are not Solaris issues AFAIK, but are due to an incompatible change in perl 5.18. The patch below should take care of it. Can you confirm it works? FWIW, it fixed the testsuite problem for me (after change to perl 5.18). I also don't see any problem in your patch. Thanks for confirming. Will push once the other issues related to this report has been fixed as well. Best regards, Stefano
bug#14760: GNU Automake 1.14 testsuite failures on -current NetBSD/amd64
On 07/22/2013 02:49 PM, Nicolas Joly wrote: On Sun, Jul 21, 2013 at 11:50:47PM +0100, Stefano Lattarini wrote: tags 14760 + moreinfo thanks On 07/01/2013 04:05 PM, Nicolas Joly wrote: Hi, Hi Nicolas, sorry for the shameful delay. No worries, i had almost no time these days to have a closer look myself. Just got 2 failures running Automake 1.14 testsuite on -current NetBSD/amd64. [SNIP] FAIL: t/silent-custom Does the patch below help with this failure? Yes, thanks. With your patch applied, t/silent-custom testcase is successful. njoly@lynche [src/automake-1.14] make -k recheck FAIL: t/parallel-tests-concurrency.sh PASS: t/silent-custom.sh Testsuite summary for GNU Automake 1.14 Thanks for letting me know. I'll apply the patch then, but also keep the bug open until the still-present failure is solved (or at least understood). Regards, Stefano
bug#14898: automake-1.14 test failures on Mac OS X
tags 14898 + moreinfo stop Hi Diab, and thanks for the report. On 07/18/2013 02:51 PM, Diab Jerius wrote: I'm seeing test failures on OS X 10.6.8 with automake-1.14 with the patches from the following bug reports applied: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14706 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14707 The following tests fail: FAIL: t/ccnoco-lt FAIL: t/fort5 FAIL: t/objc-megademo I've attached the test-suite.log file. Actually, you haven't ;-) Could you please re-send it? Or better again, if you have time, open one new bug report for each failing test (and send along only the log for that test). Thank you, Stefano
bug#14911: automake-1.14 t/ccnoco-lt failure on OS X
On 07/22/2013 03:35 AM, Hanspeter Niederstrasser wrote: On 7/21/2013 11:49 AM, Stefano Lattarini wrote: tags 14911 + patch severity 14911 minor thanks This patch allowed t/ccnoco-lt to PASS. Thanks for confirming, will push shortly. One nit: It is for bug#14911, not bug#14991 as mentioned in the comment. Good catch! Will fix that before pushing. Thank you for the quick solution. Hanspeter Thanks, and best regards, Stefano
bug#14840: Fwd: basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail
On 07/14/2013 08:34 AM, Vasiliy wrote: Dear Stefano, Many thanks for responding swiftly to my report, and for your efforts in maintaining AutoMake. I'm more than happy to provide you with my complete name, also with my personal email for any further references: Vasyl Khalak basiliom...@gmail.com Thanks, I will add this to THANKS before pushing out the patch. [SNIP] Best regards, Stefano
bug#14707: automake 1.14 test hang for t/compile4.sh on Linux if cl executable is in path
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14707 On 06/28/2013 10:25 PM, Diab Jerius wrote: [SNIP] That fixes the problem. Thanks, will push shortly then. I'm also closing the bug report. Best regards, Stefano
bug#14706: Mac OS X gcc and bogus warnings about *.dSYM directories
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14706 On 07/17/2013 05:02 PM, Diab Jerius wrote: [SNIP] I've tried this on OSX 10.6.8 and 10.7 and t/depcomp2 now passes. Diab Thanks for letting me know; I will push the patch shortly then. I'm also closing this bug report. Thank you, Stefano
bug#14911: automake-1.14 t/ccnoco-lt failure on OS X
tags 14911 + patch
severity 14911 minor
thanks
On 07/19/2013 10:24 PM, Nick Bowler wrote:
On 2013-07-19 11:48 -0400, Hanspeter Niederstrasser wrote:
On OS X 10.7, t/ccnoco-lt fails with the following error (from
test-suite.log). For completeness sake, t/depcomp2 also failed, but I
applied the patch from #14706 and that allowed depcomp2 to pass.
--- 8 --- 8 --- 8 ---
FAIL: t/ccnoco-lt
=
[...]
libtool: link:
/sw/build.build/automake1.14-1.14-1/automake-1.14/t/ccnoco-lt.dir/compile
/sw/build.build/automake1.14-1.14-1/automake-1.14/t/ax/cc-no-c-o
-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libwish.0.dylib
.libs/libwish.o -L/sw/lib -O2 -install_name
/usr/local/lib/libwish.0.dylib -compatibility_version 1 -current_version
1.0 -Wl,-single_module
/sw/build.build/automake1.14-1.14-1/automake-1.14/t/ax/cc-no-c-o: both
'-o' and '-c' seen on the command line
make: *** [libwish.la] Error 2
Looks like a false negative to me.
Automake uses a deliberately-crippled compiler wrapper which is designed
to reject command-lines with -c and -o for testing purposes, found in
automake/t/ax/cc-no-c-o. The problem appears to be that the wrapper's
test of the command line arguments is too simplistic, and incorrectly
considers the above command line as a using both -c and -o, when it
clearly does not.
So the test will need to be made more robust.
Agreed. Could anybody test the patch below?
Thanks,
Stefano
8 --- 8 8 --- 8 8 --- 8 8 --- 8
From 4d7dcafc0f419378cd80e46f9390950c6fbaffa0 Mon Sep 17 00:00:00 2001
Message-Id:
4d7dcafc0f419378cd80e46f9390950c6fbaffa0.1374421729.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 21 Jul 2013 13:46:48 +0100
Subject: [PATCH] test: avoid false positives in 'cc-no-c-o' script
Fixes automake bug#14991.
* t/ax/cc-no-c-o.in: Be more careful in determining whether both the
'-c' and '-o' options have been passed on the command line to the
compiler. In particular, do not spuriously complain in the face of
options like '-compatibility_version' or '-current_version' (seen on
Mac OS X 10.7).
* THANKS: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
THANKS| 1 +
t/ax/cc-no-c-o.in | 20
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/THANKS b/THANKS
index b708943..1482da2 100644
--- a/THANKS
+++ b/THANKS
@@ -145,6 +145,7 @@ Gwenole Beauchesne gbeauche...@mandrakesoft.com
H.J. Lu h...@lucon.org
H.Merijn Brand h.m.br...@hccnet.nl
Hans Ulrich Niedermann h...@n-dimensional.de
+Hanspeter Niederstrasserf...@snaggledworks.com
Harald Dunkel har...@coware.com
Harlan Stennharlan.st...@pfcs.com
He Li tippa...@yahoo.com
diff --git a/t/ax/cc-no-c-o.in b/t/ax/cc-no-c-o.in
index c18f9b9..bbc9ec9 100644
--- a/t/ax/cc-no-c-o.in
+++ b/t/ax/cc-no-c-o.in
@@ -19,11 +19,23 @@
am_CC=${AM_TESTSUITE_GNU_CC-'@GNU_CC@'}
-case $* in
- *\ -c*\ -o* | *\ -o*\ -c*)
+seen_c=false
+seen_o=false
+
+for arg
+do
+ case $arg in
+-c)
+ seen_c=true;;
+# It is acceptable not to leave a space between the '-o' option
+# and its argument, so we have to cater for that.
+-o|-o*)
+ seen_o=true;;
+ esac
+ if $seen_c $seen_o; then
echo $0: both '-o' and '-c' seen on the command line 2
exit 2
-;;
-esac
+ fi
+done
exec $am_CC $@
--
1.8.3.1.605.g85318f5
bug#14891: GNU Automake 1.14 FAIL: 5
Reference:
On 07/17/2013 01:47 PM, Dennis Clarke wrote:
FAIL: t/test-extensions.sh
Please try the patch below for this, and let me know if it
fixes this spurious failure.
Thanks,
Stefano
8 8 8 --- 8 8 8 8 8
From 9ac9b2ceef705596cdf77501ea2669f17d1f280e Mon Sep 17 00:00:00 2001
Message-Id:
9ac9b2ceef705596cdf77501ea2669f17d1f280e.1374423800.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 21 Jul 2013 17:15:38 +0100
Subject: [PATCH] tests: avoid use of intervals to capitalize letters
It was causing spurious failures with with Solaris 8 'tr'.
See automake bug#14891.
* t/test-extensions.sh: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/test-extensions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-extensions.sh b/t/test-extensions.sh
index 0700991..ca7c5ec 100644
--- a/t/test-extensions.sh
+++ b/t/test-extensions.sh
@@ -39,7 +39,7 @@ $AUTOMAKE -a
grep -i 'log' Makefile.in # For debugging.
for lc in $valid_extensions; do
- uc=$(echo $lc | tr '[a-z]' '[A-Z]')
+ uc=$(echo $lc | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ)
$FGREP \$(${uc}_LOG_COMPILER) Makefile.in
grep ^${uc}_LOG_COMPILE = Makefile.in
grep ^\.${lc}\.log: Makefile.in
--
1.8.3.1.605.g85318f5
bug#14891: [PATCH] automake: account for perl hash order randomization (was: Re: bug#14891: GNU Automake 1.14 FAIL: 5)
On 07/17/2013 01:47 PM, Dennis Clarke wrote:
FAIL: t/preproc-errmsg.sh
FAIL: t/primary-prefix-invalid-couples.tap 280 - ...
These are not Solaris issues AFAIK, but are due to an incompatible
change in perl 5.18. The patch below should take care of it.
Can you confirm it works?
Thanks,
Stefano
8 8 8 8 8 8 8 8
From 92a253fb8092a71b8c99b3d20073d584c239bf1c Mon Sep 17 00:00:00 2001
Message-Id:
92a253fb8092a71b8c99b3d20073d584c239bf1c.1374429593.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 21 Jul 2013 17:58:05 +0100
Subject: [PATCH] automake: account for perl hash order randomization
Try to explicitly order the keys of some perl hashes when looping
on them to do sanity/correctness checks and possibly display warning
messages; this should ensure a more reproducible output. Not really
a big deal, but I prefer to keep the order of such output reproducible
if possible.
Issue revealed by spurious testsuite failures with perl 5.18, as
reported in automake bug#14891. See also:
http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Hash_randomization
http://onionstand.blogspot.ie/2012/12/are-you-relying-on-hash-keys-being.html
* lib/Automake/Variable.pm (variables): Explicitly order the values of
the returned Automake::Variable instances.
(variables_dump): Simplify, using the knowledge that 'variables()' now
sorts its output.
* t/preproc-errmsg.sh: Adjust.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
lib/Automake/Variable.pm | 14 +++---
t/preproc-errmsg.sh | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index f1559f5..4751563 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -317,21 +317,21 @@ use vars '%_variable_dict', '%_primary_dict';
sub variables (;$)
{
my ($suffix) = @_;
+ my @vars = ();
if ($suffix)
{
if (exists $_primary_dict{$suffix})
{
- return values %{$_primary_dict{$suffix}};
- }
- else
- {
- return ();
+ @vars = values %{$_primary_dict{$suffix}};
}
}
else
{
- return values %_variable_dict;
+ @vars = values %_variable_dict;
}
+ # The behaviour of the 'sort' built-in is undefined in scalar
+ # context, hence we need an ad-hoc handling for such context.
+ return wantarray ? sort { $a-name cmp $b-name } @vars : scalar @vars;
}
=item CAutomake::Variable::reset
@@ -1080,7 +1080,7 @@ For debugging.
sub variables_dump ()
{
my $text = all variables:\n{\n;
- foreach my $var (sort { $a-name cmp $b-name } variables)
+ foreach my $var (variables())
{
$text .= $var-dump;
}
diff --git a/t/preproc-errmsg.sh b/t/preproc-errmsg.sh
index 704562d..87bcf81 100644
--- a/t/preproc-errmsg.sh
+++ b/t/preproc-errmsg.sh
@@ -58,11 +58,11 @@ Makefile.am:2: 'sub/local.mk' included from here
sub/local.mk:3: 'sub-two.a' is not a standard library name
sub/local.mk:3: did you mean 'libsub-two.a'?
Makefile.am:2: 'sub/local.mk' included from here
-Makefile.am:1: variable 'x1_SOURCES' is defined but no program or
-Makefile.am:1: library has 'x1' as canonical name (possible typo)
sub/local.mk:4: variable 'sub_x2_SOURCES' is defined but no program or
sub/local.mk:4: library has 'sub_x2' as canonical name (possible typo)
Makefile.am:2: 'sub/local.mk' included from here
+Makefile.am:1: variable 'x1_SOURCES' is defined but no program or
+Makefile.am:1: library has 'x1' as canonical name (possible typo)
END
# We need to break these substitutions into multiple sed invocations
--
1.8.3.1.605.g85318f5
bug#14775: automake 1.13.3 warning about version mismatch
tags 14775 notabug close 14775 thanks Hi Peter, sorry for the delay. On 07/03/2013 12:46 AM, Peter Johansson wrote: Hi, This is probably already fixed with the version scheme and everything, Actually it's not... but wanted to report it just in case. ... so you did well. Thanks. I updated from from automake 1.13 to 1.13.3 and after having modified an Makefile.am, Automake complained about version mismatch. I suspect aclocal.m4 was created with aclocal 1.13 (?). I think so, yes. This is easily resolved by running autoreconf -if, but I found it odd that a patch upgrade should cause that minor head ache. Especially since I then upgraded to Automake 1.14 and expected the same thing to happen, but no - now if I issue 'make' it will happily keep running automake-1.13 (which is version 1.13.3 obviously). So in short upgrading a patch version cause version mishmash but upgrading a minor version is smoother than expected. Is this still the case with 1.14, 2.0 etc? Yes. If so, is it on purpose? Basically yes. Think about the following situation: 1. A user has generated his Makefile.in with Automake 1.14. 2. We release Automake 1.14.1, that contains a bug fix that involves changing some internal details in AM_INIT_AUTOMAKE. 3. The user upgrades to Automake 1.14.1, without re-running autoreconf. 4. Remember that the old (1.14) AM_INIT_AUTOMAKE definition has been copied by the the old aclocal 1.14 in the generated aclocal.m4, and it's still there, even after the Automake upgrade. 4. The user modifies his Makefile.am, and re-run 'make'. 5. automake 1.14.1 is run, expecting to be able to rely on the new version of the AM_INIT_AUTOMAKE internals. But that expectation is *wrong*, since the AM_INIT_AUTOMAKE present in aclocal.m4 is still the one from Automake 1.14, and it is not going to be changed, since aclocal is not being re-run. 6. Possible inconsistencies or spurious errors ensue. Oops. So I believe the current strict version checking is actually necessary, albeit possibly a little annoying for the user. Remember, the rule of thumb is the following: * Whenever you upgrade any component of the Auto* toolchain, re-run autoreconf --force -- even if it is just a micro version upgrade. In the hope you'll agree with my reasoning above, I'm pre-emptively closing the bug report. If you don't agree, feel free to re-open it and continue the discussion here (and of course feel free to continue the discussion even if you do agree, but still have something to add :-) Thanks, Stefano
bug#14760: GNU Automake 1.14 testsuite failures on -current NetBSD/amd64
tags 14760 + moreinfo
thanks
On 07/01/2013 04:05 PM, Nicolas Joly wrote:
Hi,
Hi Nicolas, sorry for the shameful delay.
Just got 2 failures running Automake 1.14 testsuite on -current
NetBSD/amd64.
[SNIP]
FAIL: t/silent-custom
Does the patch below help with this failure?
(As for the other failure, I'll take a look later -- might be
few minutes, might be few days).
Thanks,
Stefano
8 8 8 8 8 8 8
From ac0e09477ca1614892799c91c327fff0ba83ad19 Mon Sep 17 00:00:00 2001
Message-Id:
ac0e09477ca1614892799c91c327fff0ba83ad19.1374445534.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 7 Jul 2013 11:37:37 +0100
Subject: [PATCH] tests: fix a spurious failure on NetBSD-current
Reported in automake bug#14760.
* tests/silent-custom.sh: Be prepared to handle creative
quoting in the output of the shell run for the make recipes
when the shell traces are active (set -x).
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
t/silent-custom.sh | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/silent-custom.sh b/t/silent-custom.sh
index 7ce3ffc..b00e388 100644
--- a/t/silent-custom.sh
+++ b/t/silent-custom.sh
@@ -80,8 +80,18 @@ do_check ()
else
$FGREP 'GEN ' output exit 1
$FGREP 'cp ./foo.in foo' output
-$FGREP rm -f sub/0.h sub/1.h sub/2.h output
-$FGREP generate-header --flags sub/0.h sub/1.h sub/2.h output
+# Be prepared to handle creative quoting in the shell traces.
+# See automake bug#14760.
+ok=false
+for q in '' \' \; do
+ files=${q}sub/0.h${q} ${q}sub/1.h${q} ${q}sub/2.h${q}
+ $FGREP rm -f $files output || continue
+ $FGREP generate-header --flags $files output || continue
+ ok=:
+ break
+done
+$ok || exit 1
+unset ok
fi
}
--
1.8.3.1.605.g85318f5
bug#14728: filenames starting with a dash confuse automake
severity 14728 minor stop Hello, sorry for the delay. On 06/28/2013 07:22 PM, Josh Triplett wrote: On Thu, Jun 27, 2013 at 09:55:53AM +0200, Stefano Lattarini wrote: On 06/27/2013 06:37 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi, I encountered this in systemd, which recently added a file with a dash in the name [1]. I fear this falls in the category Doctor, it hurts when I do that -- Don't do that, then :-) To elaborate, on Unix systems, having filenames starting with a dash has always been very problematic, and generally a terrible idea. Do you have a very, *very* good reason to have such a file? One obvious reason: as part of a test suite for just such a problem. I'm not sure this qualifies as a very good reason, sorry. Anyone on Unix using system files whose name start with a dash deserves to suffer a bit ;-) Basically, various commands like install and rm are called without guarding the file list with --, That's because such usage might be unportable; well, it surely was in the olden days, but I'm not sure whether that is still relevant on today's system. Still, I'm not comfortable changing the old assumption and risking regressions for the users of oldish or proprietary systems. Putting -- before the file list might not be portable, but prefixing filenames starting with a - with ./ seems completely portable. Would that work? Yes, but it might complicate or slow down the code, and I think it's not really worth spending time on it. I won't refuse a patch in this direction though, *if* it doesn't complicate or slow-down the code. Otherwise, I will close this bug as wontfix sometime in the nearish future. Thanks, Stefano
bug#14707: automake 1.14 test hang for t/compile4.sh on Linux if cl executable is in path
On 06/28/2013 10:25 PM, Diab Jerius wrote: That fixes the problem. Thanks, Diab Thanks for confirming. I will push the patch soonish then (maybe a few days). Best regards, Stefano
bug#14728: filenames starting with a dash confuse automake
tags 14728 + moreinfo severity 14728 minor stop On 06/27/2013 06:37 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi, I encountered this in systemd, which recently added a file with a dash in the name [1]. I fear this falls in the category Doctor, it hurts when I do that -- Don't do that, then :-) To elaborate, on Unix systems, having filenames starting with a dash has always been very problematic, and generally a terrible idea. Do you have a very, *very* good reason to have such a file? Basically, various commands like install and rm are called without guarding the file list with --, That's because such usage might be unportable; well, it surely was in the olden days, but I'm not sure whether that is still relevant on today's system. Still, I'm not comfortable changing the old assumption and risking regressions for the users of oldish or proprietary systems. Anyway, if you can send a patch that fixes the issue for you without risking regressions or complicating the code base, I'm ready to consider it (no promise though). which causes them to interpret the file name as an option. In case of systemd, 'make uninstall' and thus 'make distcheck' are affected, but depending on the type of the file (SCRIPT, DATA, etc), other targets can be affected. $ make install DESTDIR=/var/tmp/inst2 make[1]: Entering directory `home/zbyszek/src/automake-dash' /usr/bin/mkdir -p '/var/tmp/inst2/usr/local/bin' /usr/bin/install -c -.sh '/var/tmp/inst2/usr/local/bin' /usr/bin/install: invalid option -- '.' Attached toy project reproduces this error. Thanks, Zbyszek [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=4ad49000 So, in conclusion, I'm 90-10 for closing this bug as a wontfix; although a simple patch or the explanation of a *very* good reason for having a dash-starting filename might change my mind. For the moment, I'm thus not closing the bug. Regards, Stefano
bug#14707: automake 1.14 test hang for t/compile4.sh on Linux if cl executable is in path
On 06/25/2013 06:12 PM, Diab Jerius wrote: On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote: severity 14707 minor tags 14707 + moreinfo thanks On 06/24/2013 04:45 PM, Diab Jerius wrote: Hi, Hi Diab, thanks for the report. On the Linux boxes I compile on, there's a /usr/local/bin/cl executable (from the IRAF package). Unfortunately, it seems that t/compile4.sh interprets that as a Microsoft compiler. The IRAF cl is an interactive program, What happens if the program is run with its stdin redirected from /dev/null? Does it exit immediately, or does it still hang? Also, does the program support a --version or --help option that might lead us to rule it out? so compile4.sh invokes it and it hangs waiting for input. (Which is quite annoying indeed). Is there perhaps a better way of checking for the Microsoft compiler, or restricting these tests to Microsoft operating systems? I'd rather try the workarounds I proposed above first. If they don't work, we should go along with your suggestion. Thank you, Stefano As the tests progress, it looks like there are more with the same issue. Not to worry, those tests all share the same code for requesting prerequisites, so the all the issues should disappear once we fix the code for the cl requirement. Patch coming up soon... For completeness, here's the list: t/compile4.sh t/depcomp-lt-msvcmsys.tap t/depcomp-lt-msvisualcpp.tap t/depcomp-msvcmsys.tap t/depcomp-msvisualcpp.tap Thanks, Stefano
bug#14707: automake 1.14 test hang for t/compile4.sh on Linux if cl executable is in path
tags 14707 + patch tags 14707 - moreinfo thanks On 06/24/2013 11:35 PM, Diab Jerius wrote: On Mon, 2013-06-24 at 23:22 +0200, Stefano Lattarini wrote: On 06/24/2013 04:45 PM, Diab Jerius wrote: On the Linux boxes I compile on, there's a /usr/local/bin/cl executable (from the IRAF package). Unfortunately, it seems that t/compile4.sh interprets that as a Microsoft compiler. The IRAF cl is an interactive program, What happens if the program is run with its stdin redirected from /dev/null? Does it exit immediately, or does it still hang? It exits, quite verbosely: % cl /dev/null Warning: no login.cl found in login directory apropos fitsutillists phist stecf utilities color gemini mscred plotstlocal xray ctiogmisc nmisc proto stsdas dataio images noaorvsao system dbmslanguageobsoletesoftoolstables ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl ERROR: use `logout' to log out of the CL ecl % Thanks, this is what I needed. Below is a patch that I hope should fix your problem. Can you give it a try? Also, does the program support a --version or --help option that might lead us to rule it out? Indeed, it does: % cl --version NOAO/IRAFNET PC-IRAF Revision 2.14.1 Mon Sep 15 10:12:05 MST 2008 so compile4.sh invokes it and it hangs waiting for input. (Which is quite annoying indeed). Thanks, Stefano 8 8 8 8 8 8 8 8 From ec163633dd590bfdbd8d7fd147492081018507f7 Mon Sep 17 00:00:00 2001 Message-Id: ec163633dd590bfdbd8d7fd147492081018507f7.1372324708.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 27 Jun 2013 11:11:35 +0200 Subject: [PATCH] tests: don't risk hanging on the 'cl' requirement On the GNU/Linux boxes of some users that run our testsuite there is a '/usr/local/bin/cl' executable, from the IRAF package: http://iraf.noao.edu/ The test 'compile4.sh' (and other tests) try to invoke the 'cl' command to check whether it's a Microsoft compiler; the IRAF cl is an interactive program, so it hangs on such invocation. In conclusion, the testsuite hangs for those users which have the IRAF cl early in PATH. Fix the issue by redirecting the input of cl from /dev/null when invoking it, which is enough to prevent the cl program from IRAF from hanging, and should have no effect on the behaviour of the Microsoft compiler. This change fixes automake bug#14707. * t/ax/am-test-lib.sh (require_tool): Adjust the handling of the 'cl' requirement. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/ax/am-test-lib.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh index 182b070..26e58ef 100644 --- a/t/ax/am-test-lib.sh +++ b/t/ax/am-test-lib.sh @@ -788,7 +788,11 @@ require_tool () # in the environment by hand before calling the testsuite. export CC CPPFLAGS echo $me: running $CC -? - $CC -? || skip_all_ Microsoft C compiler '$CC' not available + # The IRAF package (http://iraf.noao.edu/) contains a 'cl' program + # which is interactive, and which could cause the testsuite to hang + # if its standard input is not redirected. See automake bug#14707. + $CC -? /dev/null \ +|| skip_all_ Microsoft C compiler '$CC' not available ;; etags) # Exuberant Ctags will create a TAGS file even -- 1.8.3.1.448.gfb7dfaa
bug#14707: automake 1.14 test hang for t/compile4.sh on Linux if cl executable is in path
severity 14707 minor tags 14707 + moreinfo thanks On 06/24/2013 04:45 PM, Diab Jerius wrote: Hi, Hi Diab, thanks for the report. On the Linux boxes I compile on, there's a /usr/local/bin/cl executable (from the IRAF package). Unfortunately, it seems that t/compile4.sh interprets that as a Microsoft compiler. The IRAF cl is an interactive program, What happens if the program is run with its stdin redirected from /dev/null? Does it exit immediately, or does it still hang? Also, does the program support a --version or --help option that might lead us to rule it out? so compile4.sh invokes it and it hangs waiting for input. (Which is quite annoying indeed). Is there perhaps a better way of checking for the Microsoft compiler, or restricting these tests to Microsoft operating systems? I'd rather try the workarounds I proposed above first. If they don't work, we should go along with your suggestion. Thank you, Stefano
bug#14685: aclocal and AC_CONFIG_MACRO_DIR
severity 14685 minor thanks On 06/21/2013 10:19 PM, Werner LEMBERG wrote: [automake 1.14] [erroneously sent to the `automake' list] It seems that there are problems if AC_CONFIG_MACRO_DIR contains more than a single directory. That's because AC_CONFIG_MACRO_DIR (provided by Autoconf) is only meant to accept one directory as its argument. For two or more dirs, you should use AC_CONFIG_MACRO_DIRS instead (which BTW also works if only one dir is given, so I'd suggest you to unconditionally prefer it over AC_CONFIG_MACRO_DIR). But that said, ... Calling aclocal -I gnulib/m4 --force -I m4 within the attached bundle causes aclocal: error: couldn't open directory 'gnulib/m4 m4': No such file or directory ... I see this error message is definitely unclear; it could be improved to suggest you to use AC_CONFIG_MACRO_DIRS whenever you have to or more m4 directories. So I'm not closing this bug report, either until such an improved error message is implemented (as usual, patches are very welcome), or until someone proves me that my proposed change would be a bad idea. If I comment out the lines AC_CONFIG_MACRO_DIR([gnulib/m4 m4]) in `configure.ac' the call succeeds. Werner PS: Sorry for not sending a minimum example, but I don't have enough time to work on that. Not to worry, the issue is crystal-clear to us even without an example (minimal or otherwise). Thank you, Stefano
bug#14685: aclocal and AC_CONFIG_MACRO_DIR
On 06/22/2013 09:44 AM, Werner LEMBERG wrote: That's because AC_CONFIG_MACRO_DIR (provided by Autoconf) is only meant to accept one directory as its argument. For two or more dirs, you should use AC_CONFIG_MACRO_DIRS instead (which BTW also works if only one dir is given, so I'd suggest you to unconditionally prefer it over AC_CONFIG_MACRO_DIR). Well, AC_CONFIG_MACRO_DIRS is not in autoconf 2.69, and 2.70 is not released yet... Ideally, automake provides this until 2.70 is out :-) It does ;-) Since Automake 1.13 in fact (barring unseen bugs). aclocal: error: couldn't open directory 'gnulib/m4 m4': No such file or directory ... I see this error message is definitely unclear; I don't think so, the error message is just fine if the background is known. However, I think it's a bad idea to make it a fatal error. A warning is fully sufficient IMHO. I disagree. We definitely want to catch a potential user typo with a hard error, rather than an easy to miss warning. it could be improved to suggest you to use AC_CONFIG_MACRO_DIRS whenever you have to or more m4 directories. Yes. If opening a directory fails, and the directory name contains a space, tell the user that AC_CONFIG_MACRO_DIR accepts one directory only. Sine we never really supported directories with spaces in them (not in AC_CONFIG_MACRO_DIR, nor in AC_CONFIG_AUX_DIR, nor in SUBDIRS, nor in AC_CONFIG_FILES -- nowhere, basically), I'd rather raise the error message whenever a whitespace is present in the AC_CONFIG_MACRO_DIR argument, without checking for its existence. And if AC_CONFIG_MACRO_DIRS is available, suggest to use this macro instead. Once you use Automake 1.13, that macro should be made automatically available. If you've find out a situation where that's not the case, you've just found another Automake bug (in which case, please report it separately). Thanks, Stefano
bug#14685: aclocal and AC_CONFIG_MACRO_DIR
Hi Diego, thanks for chiming in. On 06/22/2013 12:19 PM, Diego Elio Pettenò wrote: Hi Werner, AC_CONFIG_MACRO_DIR expects a single directory (it's used by among other libtool to put its m4 files). AC_CONFIG_MACRO_DIRS is the one you want to use (plural form). HTH I think you've missed the second part of my conversation with Werner... Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14685 Oh, but I see that's because Werner's report has been sent to both the automake and bug-automake lists, causing some confusion. Well, now that I've added the above link the dicussion on the bug tracker, the confusion should be cleared, and the situation for potential thread-diggers from the feature should be improved :-) So, let's continue the discussion on the bug tracker only from now on, OK? Thanks, Stefano
bug#14560: C Compilation variables present in output Makefiles unconditionally
tags 14560 - moreinfo tags 14560 + patch severity 14560 minor stop [+cc automake-patches, -cc automake] On 06/11/2013 01:29 PM, Ralf Corsepius wrote: On 06/05/2013 12:03 PM, Stefano Lattarini wrote: [+cc bug-automake, so this will be registered in the bug tracker] On 06/05/2013 07:16 AM, Ralf Corsepius wrote: On 06/03/2013 09:14 PM, Stefano Lattarini wrote: We are pleased to announce the GNU Automake 1.13.3 maintenance release. When comparing automake-1.13.2 generated Makefile.ins against automake-1.13.3 generated Makefile.in, in projects which are _not_ using c I am observing changes like this one below: --- a/Makefile.in +++ b/Makefile.in ... @@ -109,6 +109,18 @@ AM_V_at = $(am__v_at_@AM_V@) am__v_at_ = $(am__v_at_@AM_DEFAULT_V@) am__v_at_0 = @ am__v_at_1 = +COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ + $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +AM_V_CC = $(am__v_CC_@AM_V@) +am__v_CC_ = $(am__v_CC_@AM_DEFAULT_V@) +am__v_CC_0 = @echo CC $@; +am__v_CC_1 = +CCLD = $(CC) +LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ +AM_V_CCLD = $(am__v_CCLD_@AM_V@) +am__v_CCLD_ = $(am__v_CCLD_@AM_DEFAULT_V@) +am__v_CCLD_0 = @echo CCLD $@; +am__v_CCLD_1 = SOURCES = DIST_SOURCES = AM_V_DVIPS = $(am__v_DVIPS_@AM_V@) ... Yeah, this shouldn't happen. Not a serious regression thankfully, but still unpleasant. So far, I havn't had sufficient time to implement a simple reproducer, but I am inclined to believe, automake-1.13.3 inserts c-compiler related vars into Makefile.ins, in cases no C-compiler is being used. Please find a reproducer enclosed below. Untar the tarball and run autoreconf -fi. Compare the files being generated by automake-1.13.2+autoconf-2.69 against those being generated by automake-1.13.3+autoconf-2.69 From what I can gather, something seems broken with automake-1.13.3's SUFFIX handling. Seems to me as is these extraneous variables are being generated when a Makefile use more than one suffix rule. Thanks, this is exactly what I needed, and your diagnosis seems spot-on. I will soon post a couple of patches that should first expose and then fix the issue. BTW, I notice your e-mail in THANKS might be outdated. Should I replace it with the one you are using recently? Regards, Stefano
bug#14560: [PATCH 0/2] Fix automake bug#14560
Will push this to 'micro' by tomorrow if there is no objection. On-field testing would be appreciated. Stefano Lattarini (2): tests: expose automake bug#14560 lang, suffix rules: don't require C stuff needlessly NEWS | 11 ++ automake.in | 9 ++--- lib/Automake/Rule.pm | 15 +--- t/list-of-tests.mk| 2 ++ t/no-extra-c-stuff.sh | 74 +++ t/no-extra-makefile-code.sh | 9 +++-- t/suffix-extra-c-stuff-pr14560.sh | 37 7 files changed, 137 insertions(+), 20 deletions(-) create mode 100644 t/no-extra-c-stuff.sh create mode 100644 t/suffix-extra-c-stuff-pr14560.sh -- 1.8.3.rc3.260.g1462b67
bug#14560: [PATCH 2/2] lang, suffix rules: don't require C stuff needlessly
This change fixes automake bug#14560: when two or more user-defined suffix
rules were present in a single Makefile.am, automake would needlessly
include definition of some make variables related to C compilation in the
generated Makefile.in.
* automake.in (handle_languages): Fix logic to decide whether or not to
include definitions of C compilation related variables in the generated
Makefile.in: instead of doing so when two or more user-defined suffix
rules are seen (which is a completely bogus criterion), do so when two
or more compiled languages are used.
* lib/Automake/Rule.pm (suffix_rules_count): Remove as no longer used.
(@EXPORT): Adjust.
* t/list-of-tests.mk (XFAIL_TESTS): No longer list the test script
'suffix-extra-c-stuff-pr14560.sh', which now passes.
* NEWS: Update.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS | 11 +++
automake.in | 9 +
lib/Automake/Rule.pm | 15 +--
t/list-of-tests.mk | 1 -
4 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/NEWS b/NEWS
index d540aab..a6f0953 100644
--- a/NEWS
+++ b/NEWS
@@ -91,6 +91,17 @@
+New in 1.13.4:
+
+* Bugs fixed:
+
+ - Fix a minor regression introduced in Automake 1.13.3: when two or more
+user-defined suffix rules were present in a single Makefile.am,
+automake would needlessly include definition of some make variables
+related to C compilation in the generated Makefile.in (bug#14560).
+
+
+
New in 1.13.3:
* Documentation fixes:
diff --git a/automake.in b/automake.in
index 63d5bdf..835d3bd 100644
--- a/automake.in
+++ b/automake.in
@@ -1572,10 +1572,11 @@ sub handle_languages
# If the project is entirely C++ or entirely Fortran 77 (i.e., 1
# suffix rule was learned), don't bother with the C stuff. But if
# anything else creeps in, then use it.
-$needs_c = 1
- if $need_link || suffix_rules_count 1;
-
-if ($needs_c)
+my @languages_seen = map { $languages{$extension_map{$_}}-name }
+ (keys %extension_seen);
+@languages_seen = uniq (@languages_seen);
+$needs_c = 1 if @languages_seen 1;
+if ($need_link || $needs_c)
{
define_compiler_variable ($languages{'c'})
unless defined $done{$languages{'c'}};
diff --git a/lib/Automake/Rule.pm b/lib/Automake/Rule.pm
index 7fe6474..a28a78d 100644
--- a/lib/Automake/Rule.pm
+++ b/lib/Automake/Rule.pm
@@ -29,8 +29,7 @@ use Automake::DisjConditions;
require Exporter;
use vars '@ISA', '@EXPORT', '@EXPORT_OK';
@ISA = qw/Automake::Item Exporter/;
-@EXPORT = qw (reset register_suffix_rule suffix_rules_count
- next_in_suffix_chain
+@EXPORT = qw (reset register_suffix_rule next_in_suffix_chain
suffixes rules $KNOWN_EXTENSIONS_PATTERN
depend %dependencies %actions register_action
accept_extensions
@@ -465,18 +464,6 @@ sub register_suffix_rule ($$$)
}
}
-=item C$count = suffix_rules_count
-
-Return the number of suffix rules added while processing the current
-FMakefile (excluding predefined suffix rules).
-
-=cut
-
-sub suffix_rules_count ()
-{
- return (scalar keys %_suffix_rules) - (scalar keys %_suffix_rules_builtin);
-}
-
=item C@list = suffixes
Return the list of known suffixes.
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index f2eb648..007094f 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -42,7 +42,6 @@ t/remake-timing-bug-pr8365.sh \
t/lex-subobj-nodep.sh \
t/subobj-indir-pr13928.sh \
t/subobj-vpath-pr13928.sh \
-t/suffix-extra-c-stuff-pr14560.sh \
t/remake-am-pr10111.sh \
t/remake-m4-pr10111.sh \
$(perl_fake_XFAIL_TESTS)
--
1.8.3.rc3.260.g1462b67
