bug#20713: aclocal/tar.m4 and solaris 5.10
Hi Karl, Am 01.06.2015 um 23:02 schrieb Karl Berry : > Running a configure script on solaris 5.10 generated with automake-1.15, > I got these errors about id, which being pre-POSIX, does not support -u: > > id: illegal option -- u > Usage: id [-ap] [user] > id: illegal option -- g > Usage: id [-ap] [user] > checking whether UID 'unknown' is supported by ustar format... > ./configure: line 4190: test: unknown: integer expression expected > no > checking whether GID 'unknown' is supported by ustar format... > ./configure: line 4200: test: unknown: integer expression expected > no This is a long-standing issue on Solaris and the fix I use is prepending /usr/xpg4/bin to PATH as there are multiple versions of id installed by default as documented in id(1m). Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
bug#54063: automake cannot run without generated Texinfo manual
On 19 Feb 2022 15:03, Patrice Dumas wrote:
> In Texinfo, we have a texinfo manual which is automatically generated
> from Pod sections from Texinfo perl modules. When this generated manual
> is removed, automake cannot run anymore. To workaround this issue, we
> have a generation of a fake manual that contains only @setfilename
> manual.info
> in the autogen.sh script that can be used to bootstrap some other
> autogenerated things, in particular Makefile fragments. However, this
> is not practical, in particular if the generated manual is removed and
> the Makefile.am file is modified, one need to redo a fake manual in
> order to have things being ok again.
>
> It seems to me that one way to avoid the issue would be if automake used
> only the texinfo manual name to construct the rules. It would probably
> be a good thing to do irrespective of this issue, as @setfilename is not
> as important as it used to be, now it is fully optional, and we probably
> should consider as a best practice not to have @setfilename in Texinfo
> manuals.
>
> The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.
automake already has some fallback logic if @setfilename isn't set -- it
uses the basename of the source file and changes .texi to .info. but it
doesn't work if the file doesn't exist. i think that should be easy to
support.
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3062,7 +3062,8 @@ sub scan_texinfo_file
{
my ($filename) = @_;
- my $texi = new Automake::XFile "< $filename";
+ my $source = -e $filename ? $filename : "/dev/null";
+ my $texi = new Automake::XFile "< $source";
verb "reading $filename";
my ($outfile, $vfile);
if this is the only thing you need, then i won't think any harder about it.
-mike
signature.asc
Description: PGP signature
bug#33819: automake-1.16.1 test failures on NetBSD
On 21 Dec 2018 10:46, Thomas Klausner wrote: > When running the self tests on NetBSD (8.99.27/amd64) with perl > 5.28.1, I see 26 test failures. > > The log is attached. from the log: > FAIL: t/instspc this seems to be due to install-sh being used over normal mkdir -p. but that should be fine by itself ... it seems you have a weird /bin/sh ? it is causing errors that shouldn't happen. the output makes it look like things are underquoted, but i checked the script and ran it locally, and it looks fine to me. > FAIL: t/instspc.tap 17 - percent in builddir > FAIL: t/instspc.tap 18 - percent in destdir > FAIL: t/instspc.tap 32 - star in destdir > FAIL: t/instspc.tap 79 - quadrigraph4 in builddir > FAIL: t/instspc.tap 80 - quadrigraph4 in destdir > FAIL: t/instspc.tap 81 - a_b in builddir > FAIL: t/instspc.tap 82 - a_b in destdir > FAIL: t/instspc.tap 83 - a__b in builddir > FAIL: t/instspc.tap 84 - a__b in destdir > FAIL: t/instspc.tap 92 - miscglob1 in destdir these are all some variation of: > + > DESTDIR=/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent > file='./%' make test-inst > ../install-sh -c -d > '/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent/%-prefix/foo' > mkdir: > /scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent/%-prefix/foo: > No such file or directory > *** Error code 1 > FAIL: t/instspc.tap 59 - space in builddir > FAIL: t/instspc.tap 60 - space in destdir > FAIL: t/instspc.tap 61 - tab in builddir > FAIL: t/instspc.tap 62 - tab in destdir these are all some variation of: > + > DESTDIR=/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-space > file='./ ' make test-inst > ../install-sh -c -d > '/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-space/ > -prefix/foo' > mkdir: unknown option -- r > usage: mkdir [-p] [-m mode] dirname ... > chmod: unknown option -- p > Usage: chmod [-R [-H | -L | -P]] [-fh] mode file ... > chmod [-R [-H | -L | -P]] [-fh] --reference=rfile file ... > mkdir: unknown option -- r > usage: mkdir [-p] [-m mode] dirname ... > *** Error code 1 > FAIL: t/install-sh-unittests > FAIL: t/instfail > FAIL: t/self-check-dir > FAIL: t/self-check-dir.tap 1 - testdir has the expected path [unset > am_create_testdir] > FAIL: t/self-check-dir.tap 2 - fully pre-populated testdir [unset > am_create_testdir] > FAIL: t/self-check-dir.tap 3 - testdir has the expected path > [am_create_testdir=empty] > FAIL: t/self-check-dir.tap 5 - do not create nor chdir in testdir > [am_create_testdir=no] > FAIL: t/install-sh-unittests-w more install-sh weirdness > FAIL: t/dist-with-unreadable-makefile-fails > FAIL: t/instfail-info > FAIL: t/instmany > FAIL: t/instmany-mans > FAIL: t/test-trs-recover2 not sure -mike signature.asc Description: PGP signature
bug#34151: GNU Automake 1.16.1 FAIL: 4 on Solaris 10 SPARC
On 20 Jan 2019 22:00, Dennis Clarke wrote: > The usual. Nothing new here. Four failed tests on ye old Solaris 10 > sparc with Oracle Studio 12.6 compiler tools. > > test-suite.log attached. from the log: > FAIL: t/dist-formats > + bzip2 -d parallel-compression-1.0.tar.bz2 > bzip2: Caught a SIGSEGV or SIGBUS whilst decompressing. > FAIL: t/dist-formats.tap 58 - gzip+bzip2+xz [check .tar.bz2 tarball] pretty sure there's nothing we can do about this. going to ignore it. > FAIL: t/instmany-python > FAIL t/instmany-python.sh (exit status: 1) > /usr/local/build/automake-1.16.1_SunOS5.10_sparc64vii+.001/t/instmany-python.dir/x-bin/my-install: > safe command line limit of 2500 characters exceeded i would guess this is the same as https://bugs.gnu.org/53340 which is now fixed in the tree. > FAIL: t/lex-clean-cxx > FAIL t/lex-clean-cxx.sh (exit status: 2) > FAIL: t/lex-depend-cxx > FAIL t/lex-depend-cxx.sh (exit status: 2) > /bin/bash ./ylwrap parsefoo.lxx lex.yy.c parsefoo.cxx -- lex > source='parsefoo.cxx' object='parsefoo.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ./depcomp \ > /opt/developerstudio12.6/bin/CC -DPACKAGE_NAME=\"lex-clean-cxx\" > -DPACKAGE_TARNAME=\"lex-clean-cxx\" -DPACKAGE_VERSION=\"1.0\" > -DPACKAGE_STRING=\"lex-clean-cxx\ 1.0\" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE_URL=\"\" -DPACKAGE=\"lex-clean-cxx\" -DVERSION=\"1.0\" -I. > -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE > -D_TS_ERRNO -m64 -xarch=sparc -dalign -erroff=%none -errtags=yes > -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xdepend=no > -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -c -o parsefoo.o > parsefoo.cxx > "parsefoo.cxx", line 84: Error: yylex() was declared before with a different > language. > 1 Error(s) detected. > gmake: *** [Makefile:491: parsefoo.o] Error 2 this is interesting. the tests do: #define YY_DECL int yylex (void) extern "C" YY_DECL; which seems your compiler cannot handle for some reason. -mike signature.asc Description: PGP signature
bug#32800: [PATCH/committed] tests: make silent-custom regex a little more robust
Fixes automake bug https://bugs.gnu.org/32800. Have the regex match the entire path with word boundaries on both sides. This should reduce false positives when the full cwd happens to match parent directories. * t/silent-custom.sh: Update the header output regex. --- t/silent-custom.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/silent-custom.sh b/t/silent-custom.sh index 01cf464b99eb..977255b1312e 100644 --- a/t/silent-custom.sh +++ b/t/silent-custom.sh @@ -74,7 +74,7 @@ do_check () $FGREP 'cp ' output && exit 1 $FGREP 'generate-header' output && exit 1 $FGREP 'rm -f' output && exit 1 -grep '[012]\.h' output && exit 1 +grep '\bsub/[012]\.h\b' output && exit 1 grep '^ XGENfoo$' output grep '^ GEN \[headers\]$' output else -- 2.34.1
bug#7610: [PATCH v2 committed] automake: support embedded \# in variable appends
Fixes automake bug https://bugs.gnu.org/7610.
Use of \# is not portable. POSIX does not provide any way of retaining
the # marker in variables. There is wide spread support for \# though
in GNU & BSD Make implementations.
Today, with plain variable assignments, Automake leaves the line alone:
foo = blah\#blah
This will leave it to the implementation to decide what to do. But if
you try to append to it, Automake follows POSIX and strips it:
foo = blah\#blah
foo += what
-> foo = blah\ what
Instead, let's issue a portability warning whenever \# is used, even if
it isn't being appended, and do not strip the \# when appending. Now:
foo = blah\#blah
foo += what
-> warning: escaping \# comment markers is not portable
-> foo = blah\#blah what
* NEWS: Mention change in \# handling.
* lib/Automake/VarDef.pm: Do not strip # if escaped.
* lib/Automake/Variable.pm: Warn if \# is used.
* t/comment12.sh: New test.
* t/comments-escaped-in-var.sh: New test.
* t/list-of-tests.mk: Add comment12.sh & comments-escaped-in-var.sh.
---
v2
- had to adjust the regex slightly to handle comments at the start of vars,
and add a new test to catch variations on it
NEWS | 3 +++
lib/Automake/VarDef.pm | 2 +-
lib/Automake/Variable.pm | 3 +++
t/comment12.sh | 44 +
t/comments-escaped-in-var.sh | 47
t/list-of-tests.mk | 2 ++
6 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 t/comment12.sh
create mode 100644 t/comments-escaped-in-var.sh
diff --git a/NEWS b/NEWS
index 512cdecd0cc5..665d8329d667 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,9 @@ New in 1.17:
drop support for them has been reversed. The ACCEPT_INFERIOR_RM_PROGRAM
setting no longer exists.
+ - Variables using escaped \# will trigger portability warnings, but be
+retained when appended. GNU Make & BSD Makes are known to support it.
+
* Obsolescent features:
- py-compile no longer supports Python 0.x or 1.x versions. Python 2.0,
diff --git a/lib/Automake/VarDef.pm b/lib/Automake/VarDef.pm
index 59af4036b35f..00d694a6fbda 100644
--- a/lib/Automake/VarDef.pm
+++ b/lib/Automake/VarDef.pm
@@ -188,7 +188,7 @@ sub append ($$$)
# VAR = foo # com bar
# Furthermore keeping '#' would not be portable if the variable is
# output on multiple lines.
- $val =~ s/ ?#.*//;
+ $val =~ s/ ?(^|[^\\])#.*/$1/;
# Insert a separator, if required.
$val .= ' ' if $val;
$self->{'value'} = $val . $value;
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index 4f6a88d61c5c..1269d5d9f40e 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -857,6 +857,9 @@ sub define ()
msg ('portability', $where, "':='-style assignments are not portable")
if $type eq ':';
+ msg ('portability', $where, "escaping \\# comment markers is not portable")
+if index ($value, '\#') != -1;
+
check_variable_expansions ($value, $where);
# If there's a comment, make sure it is \n-terminated.
diff --git a/t/comment12.sh b/t/comment12.sh
new file mode 100644
index ..e98159e40f3e
--- /dev/null
+++ b/t/comment12.sh
@@ -0,0 +1,44 @@
+#! /bin/sh
+# Copyright (C) 2022 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
bug#19961: check-local is kind of like check-hook
I think it would be a mistake to change where check-local runs, in any way. In Peter's message, it is running after any $(check_DATA). It does not seem that is still the case after your patch, Mike? (As usual, I didn't actually try it. Sorry.) Although it would be nice if there were perfect consistency from the beginning about the names and timing of -hook and -local, I strongly believe that trying to retrofit consistency is not worth creating incompatibilities. Not at all. To address the original request for something that runs before check-am, I would instead suggesting creating a new check-pre instead of changing check-local. However, since the original case can be addressed otherwise, and there are no other bug reports that require this (are there?), my actual suggestion is to do nothing. Except possibly to sharpen the rather annoyingly vague statement in the manual about timing that was already quoted: With the `-local' targets, there is no particular guarantee of execution order; typically, they are run early, but with parallel make, there is no way to be sure of that. which gives the user essentially zero information. Maybe it has to be that way, but if, apart from check-local, the OP's description of Automake's output as being X: X-local is correct, then we could at least say that "X-local" runs before "X", except for "check-local". That does not change with parallel makes. I admit the whole behavior of -local and -hook is rather unclear in my mind. As for changing the names of -local and -hook: I agree -pre and -post would have been better, but given the long history, I do not think it would be good to change the names, or support alternative/preferred names, just for the sake of names. That just seems like creating unnecessary confusion. --best, karl.
bug#7610: [PATCH] automake: support embedded \# in variable appends
Agreed that it is better to preserve the input text. Agreed that a warning is indicated, but as Stefano suggested, I think the warning should only be given if -Wportability is enabled (which it is by default, I gather), not unconditionally. From our manual: `portability' Portability issues (e.g., use of `make' features that are known to be not portable). which, so far as I can see, is what is being dealt with here. --thanks, karl.
bug#10828: [PATCH] rm: handle -f w/no arguments gracefully
Subject: bug#10828: [PATCH] rm: handle -f w/no arguments gracefully Patch looks good to me (just reading through it). Thanks for doing all that work. -k
bug#20713: aclocal/tar.m4 and solaris 5.10
if we can only test tools during configure, and the dist step requires results from that probing ... Fair enough. Patch is fine on that basis. --thanks, karl.
