Re: Bug Resilience Program of German Sovereign Tech Fund

[Paul Eggert]

On 6/6/24 15:20, Christoph Grüninger wrote:
I think we should apply for the Bug Resilience Program with their Direct 
Contributions option. This is not funding, rather a company is hired to 
do the mentioned things. It is easier to apply for and if granted should 
improve the situation.
Would it be a cost-effective? There are maybe ten people in the world 
who have current expertise to work on Automake development, all of them 
are busy, and unless I'm missing something none of these people work for 
the company in question.


Although the previous sentence (including that "ten") is just my guess, 
I hope the point is clear. A worry is that (unless the resources we're 
talking about are substantial) most of the effort spent by the company 
will go toward training employees, and only a fraction will go toward 
actually improving the bug resilience of Automake and/or Autoconf.

Re: Bug Resilience Program of German Sovereign Tech Fund

[Paul Eggert]

On 2024-06-06 10:48, Christoph Grüninger wrote:
Citing from the application you linked, I am referring to "direct 
contribution":


 > Direct Contributions will be provided by Neighborhoodie GmbH
 > and entails direct code and non-code contributions, such
 > as triaging, sorting and fixing known issues, supporting projects
 > with additional coding capacity, re-engineering/re-coding/refactoring
 > or removing code, improving documentation and contributor
 > onboarding material, as well as help implementing best practices
 > or standards for maintainability

Sounds pretty much what autoconf and automake need!


Oh I agree they need all that, it's just that Zack was talking about 
getting funding and I don't see funding mentioned there.


Unless it's understood that "entails" means "provides funding for"? If 
so, where is that sort of thing written down?

Re: Bug Resilience Program of German Sovereign Tech Fund

[Paul Eggert]

On 2024-06-06 08:10, Zack Weinberg wrote:

On Thu, Jun 6, 2024, at 10:37 AM, Dan Kegel wrote:

That's a really good idea.  Automake and Autotools in general underpin
a fair amount of key open source software, but is taken for granted.

Ideas for making the case for funding:


As near as I can make out, the Sovereign Tech Fund Bug Resilience 
Program application 
 
provides funding only for bug bounties, where the bugs are security 
vulnerabilities. (The other help it offers is all in-kind.)




I already have a mental list of things that
*ought* to be done in the near future for autoconf but I do not have the
capacity to do by myself on a volunteer basis.


How well would that mental list mesh with the idea of funding based on 
security vulnerability bounties?

bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

[Paul Eggert]

On 2023-12-19 14:54, Karl Berry wrote:

Hi Paul,

 help2man: can't get `--help' info from bin/automake
 Try `--no-discard-stderr' if option outputs to stderr

So, the obvious question is, why can't help2man run bin/automake?
Clearly it works on other systems, and it doesn't seem like this should
be especially system-dependent. Can you run bin/automake --help by hand?


$ bin/automake --help
Unrecognized escape \K passed through at bin/automake line 8135.

Here's line 8135:

  $output =~ s/^((#.*)?\n)*\K/.POSIX:\n\n/;

Solaris 10 'perl --version' says it's Perl v5.8.4. v5.8.4 is dated 2004 
but \K was added in v5.10, according to:


https://metacpan.org/release/RGARCIA/perl-5.10.0/view/pod/perl5100delta.pod#K-escape

'configure' says perl v5.6 is required and v5.10 is recommended, so 
v5.8.4 should work even if not recommended. v5.6 came out in 2000, 
v5.8.4 in 2004, v5.10 in 2007; Solaris 10 is dated 2005 and Oracle 
currently plans to support it through January 2027 
.


A simple fix would be for Automake to require Perl 5.10; this'd mean I'd 
have to build Perl to test Automake on Solaris 10.



Also, I'm assuming this failure was running from the development source
tree.  Does the release tarball work on Solaris 10?


I was using the release tarball.

bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

[Paul Eggert]

Here are the symptoms. But now that I look into it, I see the 
automake-1.16 build fails with the same symptoms. So I assume this is 
low priority.


  GEN  doc/automake-1.16.1
help2man: can't get `--help' info from bin/automake
Try `--no-discard-stderr' if option outputs to stderr
*** Error code 255
The following command caused the error:
echo "  GEN " doc/automake-1.16.1;:; HELP2MAN_NAME="Generate 
Makefile.in fi\
les for configure from Makefile.am"; export HELP2MAN_NAME; 
/opt/sfw/bin/mkdir -\
p doc  && AUTOMAKE_HELP2MAN=true ./pre-inst-env  /usr/bin/perl 
./doc/help2man -\
-output=doc/automake-1.16.1 --info-page=automake 
--name="${HELP2MAN_NAME}" bin\

/automake
make: Fatal error: Command failed for target `doc/automake-1.16.1'
$ HELP2MAN_NAME="Generate Makefile.in files for configure from 
Makefile.am" && export HELP2MAN_NAME && AUTOMAKE_HELP2MAN=true sh -x 
./pre-inst-env  /usr/bin/perl ./doc/help2man 
--output=doc/automake-1.16.1 --info-page=automake 
--name="${HELP2MAN_NAME}" bin/automake

abs_top_srcdir=/var/run/rpc_door/eggert/automake-1.16i
abs_top_builddir=/var/run/rpc_door/eggert/automake-1.16i
sep=:
PERL5LIB=/var/run/rpc_door/eggert/automake-1.16i/lib/:/var/run/rpc_door/eggert/automake-1.16i/lib/
+ export PERL5LIB
PATH=/var/run/rpc_door/eggert/automake-1.16i/bin:/var/run/rpc_door/eggert/prefix/bin:/usr/bin:/usr/perl5/bin:/usr/ccs/bin:/r/share1/src/developerstudio12.6/bin
+ export PATH
AUTOMAKE_UNINSTALLED=1
+ export AUTOMAKE_UNINSTALLED
AUTOMAKE_LIBDIR=/var/run/rpc_door/eggert/automake-1.16i/lib
+ export AUTOMAKE_LIBDIR
ACLOCAL_AUTOMAKE_DIR=/var/run/rpc_door/eggert/automake-1.16i/m4
+ export ACLOCAL_AUTOMAKE_DIR
ACLOCAL_PATH=/var/run/rpc_door/eggert/automake-1.16i/m4/acdir
+ export ACLOCAL_PATH
+ exec /usr/bin/perl ./doc/help2man --output=doc/automake-1.16.1 
--info-page=automake --name=Generate Makefile.in files for configure 
from Makefile.am bin/automake

help2man: can't get `--help' info from bin/automake
Try `--no-discard-stderr' if option outputs to stderr
$

bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)

[Paul Eggert]

On 2023-12-02 19:29, Zack Weinberg wrote:

`grep -q` *is*  in POSIX, but I seem to recall tripping over a
system that didn't have it (probably either a Solaris successor, or AIX)
during the run-up to Autoconf 2.71.


Solaris 10 /usr/bin/grep does not support -e, -E, -f, -F, -q, or -x.

Solaris 10 is supported by its supplier through January 2025; that's the 
usual guideline we use for how long to support a sorta-POSIX OS.


However, the script shouldn't use 'grep'. Instead, it should just use 
the shell's builtin pattern matching. That's faster and more portable. I 
installed the attached into Automake.


The original bug was fixed before I got to this, so I'm boldly closing 
the bug report.From 668e8a20e3561063ee7478e91c9f81bb40cfed7a Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 2 Dec 2023 21:50:45 -0800
Subject: [PATCH] Simplify recent $PERL check
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* configure.ac: Don’t spin off subprocesses to check $PERL.
---
 configure.ac | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 946fecb67..5cda80a18 100644
--- a/configure.ac
+++ b/configure.ac
@@ -68,13 +68,16 @@ AUTOMAKE="\"`pwd`/pre-inst-env\" automake-$APIVERSION"
 AC_PROG_LN_S
 
 AC_PATH_PROG([PERL], [perl])
-if test -z "$PERL"; then
+case $PERL in
+ '')
AC_MSG_ERROR([perl not found])
-elif echo "$PERL" | grep '[ 	]' >/dev/null; then
+   ;;
+ *' '* | *'	'*)
   AC_MSG_ERROR([The path to your Perl contains spaces or tabs.
 This would cause build failures later or unusable programs.
 Please use a path without spaces and try again.])
-fi
+  ;;
+esac
 
 # Save details about the selected perl interpreter in config.log.
 AM_RUN_LOG([$PERL --version])
-- 
2.40.1

Re: rhel8 test failure confirmation? [PATCH for problem affecting Automake testsuite]

[Paul Eggert]

Thanks for reporting that. I installed the attached slightly different 
patch into Autoconf on Savannah. This patch also changes one other 
instance of file timestamp comparison from < to <=. Something like this 
should appear in the next Autoconf release.From 713d9822bbfb2923115065efaefed34a0113f8a1 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 1 Apr 2023 16:44:03 -0700
Subject: [PATCH] Fix timing bug on high-speed builds
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Bogdan via Jacob Bachmeyer in:
https://lists.gnu.org/r/autoconf/2023-04/msg2.html
* bin/autom4te.in: If a file timestamp equals a dependency’s
timestamp, consider the file to be out of date.  Although this may
result in extra work, it fixes some rare timing bugs.
---
 bin/autom4te.in | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/bin/autom4te.in b/bin/autom4te.in
index 4b61f0a8..71d7e6a6 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -910,10 +910,8 @@ sub up_to_date ($)
   return 0
 if ! -f $tfile || ! -f $ofile;
 
-  # The youngest of the cache files must be older than the oldest of
+  # The younger of the cache files must be older than the oldest of
   # the dependencies.
-  # FIXME: These timestamps have only 1-second resolution.
-  # Time::HiRes fixes this, but assumes Perl 5.8 or later.
   my $tmtime = mtime ($tfile);
   my $omtime = mtime ($ofile);
   my ($file, $mtime) = ($tmtime < $omtime
@@ -926,7 +924,7 @@ sub up_to_date ($)
   # We depend at least upon the arguments.
   foreach my $dep (@ARGV)
 {
-  if ($mtime < mtime ($dep))
+  if ($mtime <= mtime ($dep))
 	{
 	  verb "up_to_date ($file): outdated: $dep";
 	  return 0;
@@ -949,7 +947,7 @@ sub up_to_date ($)
   # timestamp of that missing file was newer).
   return 0
 	if ! $dep;
-  if ($mtime < mtime ($dep))
+  if ($mtime <= mtime ($dep))
 	{
 	  verb "up_to_date ($file): outdated: $dep";
 	  return 0;
@@ -1038,7 +1036,7 @@ $icache_file = new Autom4te::XFile $icache, O_RDWR|O_CREAT;
 $icache_file->lock (LOCK_EX)
   if ($flock_implemented eq "yes");
 
-# Read the cache index if available and older than autom4te itself.
+# Read the cache index if available and younger than autom4te itself.
 # If autom4te is younger, then some structures such as C4che might
 # have changed, which would corrupt its processing.
 Autom4te::C4che->load ($icache_file)
@@ -1105,7 +1103,7 @@ else
 # Actual M4 expansion, if the user wants it, or if $output is old
 # (STDOUT is pretty old).
 handle_output ($req, $output)
-  if $force || mtime ($output) < mtime ($ocache . $req->id);
+  if $force || mtime ($output) <= mtime ($ocache . $req->id);
   }
 
 # If we ran up to here, the cache is valid.
-- 
2.37.2

bug#61671: Remove parentheses around test argument lists

[Paul Eggert]

Thanks, I installed that patch into Automake.

bug#61670: [PATCH] Improve test for blocked signals

[Paul Eggert]

Thanks, I installed that patch into Automake.

[bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

[Paul Eggert]

Thanks for the explanation. I installed those two patches into Automake.

[bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

[Paul Eggert]

On 2023-03-28 08:21, Warren Young wrote:

Surely Solaris 10 (shipped in 2005) is relegated to the role of porting target, 
getting nothing but a “dist” tarball?


Good point. I'll cc this to Dagobert Michelsen, who maintains the 
Autoconf port for Solaris 10. Dagobert, are people still running 
Autoconf on Solaris 10? If not, worrying about porting to older Perl 
should be even lower priority than it already is.


For context, this email is about GNU bug 61240:

https://bugs.gnu.org/61240

and the fallout that the latest Autoconf release candidate does not run 
on the old version of Perl installed by default on Solaris 10. See:


https://lists.gnu.org/r/autoconf/2023-03/msg00030.html

If OpenCSW already installs a new-enough Perl version then this Autoconf 
business shouldn't be a real issue. On the other hand if it's really 
trivial to keep Autoconf portable to older Perl, and if Jacob Bachmeyer 
or some other Perl expert can vouch for the change, we might as well put 
it in.



PS. I see that msg00030 was not archived at https://bugs.gnu.org/61240, 
so here is a quoted copy of the contents of msg00030 so that this stuff 
gets archived there too:



On 2023-02-07 21:29, Jacob Bachmeyer wrote:

use Exporter;
-use Time::HiRes qw(stat);
use IO::File;

+# use sub-second resolution timestamps if available,
+# carry on with one-second resolution timestamps if that is all we have
+BEGIN { eval { require Time::HiRes; import Time::HiRes qw(stat) } }


Thanks for looking into this. Sorry about the long delay.

My memory was jogged by the recent Autoconf release candidate, which requires Perl 5.10 for 
what I think is the same reason 
. This release candidate 
didn't build on my Solaris 10 server because Solaris 10 has only Perl 5.8.4. Of course I 
can work around this by also installing a recent Perl but that is a bit of a pain. I'll cc 
this email to autoc...@gnu.org to give them a heads-up about 
.

It'd be nice (though not crucial) if we could get to the bottom of this for 
Automake and to sync the result to Autoconf before the new Autoconf release 
comes out, so that Solaris 10 users of the new Autoconf need to install only 
recent GNU M4, and not also a recent Perl.

To get back to the proposed patch quoted above:

Why change from "use Time::HiRes qw(stat);" to "require Time::HiRes; import 
Time::HiRes qw(stat)"? (Again, please bear in mind that my Perl is quite rusty.)

The code formerly had "use File::stat;" before it changed to "use Time::HiRes qw(stat);". 
Why doesn't the proposed patch need to fall back to "use File::stat;" on older Perls lacking 
Time::HiRes?

Thanks again for any advice you can provide.

[bug#61240] improve high-res file timestamp in Automake

[Paul Eggert]

On 2023-02-05 21:43, Jacob Bachmeyer wrote:


Should the patch be relative to commit 
6d6fc91c472fd84bd71a1b012fa9ab77bd94efea (before the version requirement 
bump) or should it include reverting commit 
4e3744a15c4d8bdb46c11ead2fb56c5f591b714b (the version requirement bump)?


Might as well do it all at once, thanks.

[bug#61240] improve high-res file timestamp in Automake

[Paul Eggert]

On 2023-02-05 17:14, Jacob Bachmeyer wrote:

How often is Perl built to use long doubles these days?  (That was an 
option beginning with Perl 5.6.)


I doubt it's used much. It's not used in Ubuntu or Fedora, for what it's 
worth. And on some platforms (e.g., macOS on current Apple silicon) 
-Duselongdouble doesn't matter because long double is the same as double.


Besides, although it's too bad that Perl can't represent file timestamps 
precisely, that's not something Autoconf can fix.



Looking at the code, commit 01bf65daf6f6627b56fbe78fc436fd877ccd3537 
appears fine, all I am asking is that commit 
4e3744a15c4d8bdb46c11ead2fb56c5f591b714b be reverted.  The current 
Automake Git master should actually work on Perl 5.6 if Time::HiRes has 
been installed, which was possible with 5.6 although it was bundled with 
Perl beginning with the 5.7.3 development release.


Unfortunately the Perl version bump was prompted by evidence in the 
field that without making it clear that bare Perl 5.6 does not suffice, 
Autoconf and Automake fail in ways that are mysterious to their users. 
We can't expect people to install extensions in Perl 5.6 to work around 
this problem. We must make things simple and easy for installers and 
users to understand. Particularly since these are old Perl versions that 
Autoconf and Automake users are unlikely to be running (people who use 
bleeding-edge Autoconf and Automake almost invariably run recent Perl).


It would be OK to go back to requiring only 5.6 if we can write 
conditionalized code that works with 5.6 but with lower-res timestamps, 
and quietly switches to higher-res timestamps if available and works 
fine when they are available. Autoconf and Automake should not rely on 
users installing optional Perl packages or dealing with Perl's 
diagnostics when the optional stuff is missing: the code must work out 
of the box with no expertise required.


Can you write an Automake patch to do that, and test it on old Perl 
installations? 'git format-patch' form preferred. I don't have access to 
ancient Perl and am a bit squeezed for time, so I'm afraid this will 
need to be done by a Perl expert such as yourself.

[bug#61240] improve high-res file timestamp in Automake

[Paul Eggert]

On 2023-02-04 16:02, Jacob Bachmeyer wrote:
In any case, you will still need to account for the possibility that 
Time::HiRes::stat() might not actually have higher resolution, depending 
on the filesystem.


That's fine. All we want is the exact file timestamp. If the file system 
timestamp resolution is only 2 s, then we want that multiple of 2. 
Admittedly we can't get the exact file timestamp on many modern file 
systems since Time::HiRes is precise only to the nearest ~238 ns for 
today's timestamps, but the idea is to get what we easily can.



There are also the no-runtime-overhead options of using "eval { use Time::HiRes qw(stat) };" which will replace stat() with the hi-res version if it is available and continue with the regular stat() builtin if not, or "use constant HAVE_Time_HiRes => eval { use Time::HiRes };" and a conditional "if (HAVE_Time_HiRes) { ... } else { ... }" as I suggested as an improvement to Mike Frysinger's patch. 


Sorry, I don't remember seeing that suggestion. I guess it was in 
another thread. Could you resend that patch to 61...@debbugs.gnu.org and 
cc me? Preferably a patch against the latest Automake, in "git 
format-patch" format; see  
for how to get bleeding-edge Automake. The idea would be to port 
bleeding-edge Automake to Perl < 5.10 when that's easy.


Please bear in mind that I stopped coding in Perl 30 years ago and so am 
a bit rusty.

[bug#61240] improve high-res file timestamp in Automake

[Paul Eggert]

On 2023-02-03 18:27, Jacob Bachmeyer wrote:

Where are you actually using a 5.10 feature?


Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This 
does not work with Perl 5.6.


For why we bumped the version to 5.10, please see:

https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=61901a1a14fd50c03cfb1529d091554376fef286


Please do not arbitrarily bump version requirements just to bump version 
requirements.


That's not what was done here. The abovementioned URL says version 
requirements were bumped from 5.6 to 5.10 because the feature is not 
present in 5.6 (2000), is present in 5.10 (2007), and we lacked access 
to the museum pieces in the middle. If you are sure that a version 
number lower than 5.10 will do, please let us know.

[bug#61240] improve high-res file timestamp in Automake

[Paul Eggert]

I installed the attached to port a FileUtils.pm patch back from Autoconf 
into Automake. I wish Perl supported file timestamps with nanosecond 
resolution, but apparently not, so this is the best we could do easily.


Although this bumps the required Perl version from 5.6 (2000) to 5.10 
(2007), I don't think that's a problem nowadays.From 4e3744a15c4d8bdb46c11ead2fb56c5f591b714b Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 2 Feb 2023 14:13:24 -0800
Subject: [PATCH 1/2] maint: require perl 5.010 or later

This is needed for better treatment of high-res timestamps.
---
 NEWS   | 6 +-
 bin/aclocal.in | 2 +-
 bin/automake.in| 2 +-
 configure.ac   | 5 ++---
 lib/Automake/ChannelDefs.pm| 2 +-
 lib/Automake/Channels.pm   | 2 +-
 lib/Automake/Condition.pm  | 2 +-
 lib/Automake/Config.in | 2 +-
 lib/Automake/Configure_ac.pm   | 2 +-
 lib/Automake/DisjConditions.pm | 2 +-
 lib/Automake/FileUtils.pm  | 2 +-
 lib/Automake/General.pm| 2 +-
 lib/Automake/Getopt.pm | 2 +-
 lib/Automake/Item.pm   | 2 +-
 lib/Automake/ItemDef.pm| 2 +-
 lib/Automake/Language.pm   | 2 +-
 lib/Automake/Location.pm   | 2 +-
 lib/Automake/Options.pm| 2 +-
 lib/Automake/Rule.pm   | 2 +-
 lib/Automake/RuleDef.pm| 2 +-
 lib/Automake/VarDef.pm | 2 +-
 lib/Automake/Variable.pm   | 2 +-
 lib/Automake/Version.pm| 2 +-
 lib/Automake/Wrap.pm   | 2 +-
 lib/Automake/XFile.pm  | 2 +-
 25 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/NEWS b/NEWS
index 8cba8b3fe..cb325642f 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,10 @@ please see NEWS-2.0 and start following the advice there now.
 
 New in 1.17:
 
+* Version requirements:
+
+  - Perl 5.10 (2007) or greater is required.
+
 * New features added
 
   - RANLIB may be overridden on a per-target basis.
@@ -36,7 +40,7 @@ New in 1.17:
 and -Q is not used, since its support and behavior varies.
 
   - Emacs Lisp compilations respects silent make output.
-  
+
   - distcleancheck ignores "silly rename" files (.nfs* .smb* .__afs*)
 that can show up on network file systems.
 
diff --git a/bin/aclocal.in b/bin/aclocal.in
index f04cb30d8..34c253048 100644
--- a/bin/aclocal.in
+++ b/bin/aclocal.in
@@ -19,7 +19,7 @@
 # Written by Tom Tromey , and
 # Alexandre Duret-Lutz .
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/bin/automake.in b/bin/automake.in
index 139d5ad93..afd296afa 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -22,7 +22,7 @@
 
 package Automake;
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/configure.ac b/configure.ac
index dcf2d9556..bf72023e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,10 +73,9 @@ if test -z "$PERL"; then
 fi
 # Save details about the selected perl interpreter in config.log.
 AM_RUN_LOG([$PERL --version])
-$PERL -e 'require 5.006;' || {
+$PERL -e 'require 5.010;' || {
AC_MSG_ERROR(
-[perl 5.6 or better is required; perl 5.8.2 or better
-is recommended.  If you have several perl versions
+[perl 5.10 (2007) or better is required.  If you have several perl versions
 installed, select the one Automake should use using
   ./configure PERL=/path/to/perl])
 }
diff --git a/lib/Automake/ChannelDefs.pm b/lib/Automake/ChannelDefs.pm
index 1c436645e..bfe5ba548 100644
--- a/lib/Automake/ChannelDefs.pm
+++ b/lib/Automake/ChannelDefs.pm
@@ -44,7 +44,7 @@ shorthand function to output on specific channels.
 
 =cut
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/lib/Automake/Channels.pm b/lib/Automake/Channels.pm
index b4563d36e..5a36c93af 100644
--- a/lib/Automake/Channels.pm
+++ b/lib/Automake/Channels.pm
@@ -66,7 +66,7 @@ etc.) that can also be overridden on a per-message basis.
 
 =cut
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/lib/Automake/Condition.pm b/lib/Automake/Condition.pm
index 31ac81d80..d1e6811e8 100644
--- a/lib/Automake/Condition.pm
+++ b/lib/Automake/Condition.pm
@@ -15,7 +15,7 @@
 
 package Automake::Condition;
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/lib/Automake/Config.in b/lib/Automake/Config.in
index 4fc918b58..3cc094d15 100644
--- a/lib/Automake/Config.in
+++ b/lib/Automake/Config.in
@@ -17,7 +17,7 @@
 
 package Automake::Config;
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/lib/Automake/Configure_ac.pm b/lib/Automake/Configure_ac.pm
index efd428e2a..d4751ee26 100644
--- a/lib/Automake/Configure_ac.pm
+++ b/lib/Automake/Configure_ac.pm
@@ -20,7 +20,7 @@
 
 package Automake::Configure_ac;
 
-use 5.006;
+use 5.010;
 use strict;
 use warnings FATAL => 'all';
 
diff --git a/lib/Automake/DisjConditions.pm b/lib/Automake/DisjConditions.pm
index 16540e7da..7612f607c 10

Re: portability of xargs

[Paul Eggert]

On 2/14/22 20:03, Mike Frysinger wrote:

are the corner cases known ?


I don't know of a catalog, no.

These days you might have better luck with "find ... -exec ... {} +". 
Although standardized more recently than xargs, my vague impression is 
that there's less variation among implementations. It works only on file 
names, though.

Re: portability of xargs

[Paul Eggert]

On 2/14/22 19:45, Mike Frysinger wrote:

how portable is xargs ?


It can be a porting problem, unfortunately. There are several corner 
cases that various implementations don't get right. I expect this is why 
the GNU Coding Standards exclude xargs from the list of programs that 
'configure' and Makefile rules can use.

bug#50469: [bison-3.8] bug or side effect to flex & automake

[Paul Eggert]

On 9/11/21 4:03 AM, Kiyoshi KANAZAWA wrote:


Failures of flex's make check also disappeared with bison-3.8.1.


Thanks for testing, and thanks Akim for writing the patch. I installed 
it on the automake master branch on Savannah.

bug#50469: [bison-3.8] bug or side effect to flex & automake

[Paul Eggert]

On 9/8/21 2:18 PM, Karl Berry wrote:

Just an idea that I don't expect you to adopt, but just to mention --
you could only institute the breaking change if POSIXLY_CORRECT.  That's
why POSIXLY_CORRECT exists. -k


I like this idea. It insulates us against POSIX decisions and/or 
indecisions in this area.

bug#50469: [bison-3.8] bug or side effect to flex & automake

[Paul Eggert]

On 9/7/21 10:31 PM, Akim Demaille wrote:

However, I don't see a published version of the POSIX Yacc "specs" that 
includes these changes.


The next POSIX revision is targeted for 2022, according to 
.


I suppose there is still opportunity to fix POSIX before the next 
revision comes out, but someone would have to create a bug report and 
submit it to the Austin Group.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 12:26 PM, Paul Eggert wrote:

On 3/9/21 11:09 AM, Karl Berry wrote:


I fully disagree. (Along with, it seems, everyone else except
you and Ben.)


Ben is the main person to convince here, since he's the maintainer.


Oh, my mistake. Ben has stepped down, so I should have written that 
Dmitry is the main person to convince here, since he's the maintainer of 
'config' now.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 11:09 AM, Karl Berry wrote:


I fully disagree. (Along with, it seems, everyone else except
you and Ben.)


Ben is the main person to convince here, since he's the maintainer.

I am a bit disenheartened to see that Ben hasn't sent any email to this 
list since he installed the change in question, back in November. If 
he's retired (which I hope not), we'll need to find a new maintainer 
whose lap we can dump this problem into. I'll cc this email to him to 
give him a heads-up about the thread.



1) There is no actual benefit to using $(...) over `...`.


I disagree with that statement on technical grounds (not merely cosmetic 
grounds), as I've run into real problems in using `...` along with " and 
\, problems that I would not have run into with $(...). The Autoconf 
manual describes some of these problems.[1]



Talking about # as an analogy is a red herring. # does not cause
real-life problem.


# caused a real-life problem for me on a real-life system, around 1979. 
Of course the problem set has changed since then, but the compatibility 
principle hasn't.


[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Shell-Substitutions.html

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/9/21 5:57 AM, Bob Friesenhahn wrote:

It seems that config.guess and Autotools packages are picking winners 
and losers.  It is not clear where the bar has been set.


I prefer to draw the line at systems that are no longer supported by 
their own suppliers. For Solaris, that means I worry only about Solaris 
10 and later, as Oracle no longer supports older versions.


However, this is not a boundary formally set by the GNU project, and 
different developers can choose different boundaries, as described in 
"Platforms to Support" section of the GNU software maintainers manual 
.


config.sub/config.guess are special in that they're shared among so many 
projects, and so the boundary that Ben uses affects a lot of projects' 
configuration code.

Re: config.sub/config.guess using nonportable $(...) substitutions

[Paul Eggert]

On 3/8/21 3:00 PM, Dmitry V. Levin wrote:

The only rationale provided by the previous maintainer so far is a short
message in config-patches mailing list [1].


The config maintainer Ben Elliston has wanted to get rid of the 
old-fashioned accent graves for many years. In November 2017 he 
installed a change to do that, but I explained it wouldn't work well on 
Solaris 10 so he reverted. Two years ago he asked me about this again, 
and I responded that Solaris 10's end-of-life was scheduled to be 
January 2021 and so it'd be best to wait until then, and he agreed. Last 
April we emailed each other again about this, and I told him that Oracle 
had extended Solaris 10's end-of-life to January 2024 but he demurred, 
writing that he didn't want to wait the extra three years.


Except maybe for Solaris 10, shells that don't grok $(...) are museum 
pieces now. And anybody on Solaris 10 (which occasionally includes me, 
as my department still uses Solaris 10 on some machines) can easily run 
a better shell like /bin/ksh. It's a bit of a maintenance hassle for Ben 
to deal with `...` (it doesn't nest, and it has weird rules when 
combined with "...") and it's understandable that he would rather deal 
with actual config.guess problems than with completely-obsolete shells 
that don't support standard syntax.


I recall having a similar discussion back in the 1970s, when a shell 
script stopped working for me because its author put in a comment 
starting with "#", something the 7th Edition shell did not support. I 
wrote the author, who suggested I get a better shell, and life went on. 
And I'd expect a similar reaction today if someone asked us to remove 
the "#" comments from config.guess on the grounds that they don't work 
with Steve Bourne's original V7 shell.


At some point, failing to support $(...) is in the same ballpark as 
failing to support "#". I can see Ben's point of view that we've reached 
that point even if I would have waited another three years, so if Ben 
would rather use $(...) I'd rather not overrule him downstream.

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

[Paul Eggert]

On 1/29/21 12:03 PM, Zack Weinberg wrote:


Perl 5.18.0 was released in May 2013.  (Perl 5.6.0 was released in
March 2000.)  I selected it as the minimum because the Perl
maintainers recommend all users of older interpreters upgrade to at
least this version, due to security fixes (see
https://perldoc.perl.org/perlsec#Algorithmic-Complexity-Attacks --
inputs to Autoconf and Automake are trusted, but this rationale means
it's hard to find a CI platform that offers anything older than 5.18,


This seems pretty conclusive.

The laggards in this area are the old, stable software distros like Red 
Hat. For example, although RHEL 7.7 (supported through August) still 
ships with Perl 5.16.3 (with patches), Red Hat ships and supports Perl 
5.30.1 for this platform as part of the Red Hat Software Collections. I 
would hope for something similar among the other distros.


An extreme case of this would be Solaris 10, still shipping perl 5.8.4 
(2004) with patches, and still supported by Oracle until January 2024. 
But anyone who wants to build on this old platform already needs to 
bring in recent-enough GNU m4, so adding Perl to the list shouldn't faze 
them much.

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

[Paul Eggert]

On 1/28/21 10:34 AM, Zack Weinberg wrote:

we could instead use the
battle-tested technique used by Emacs: symlink sentinels.  (See
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c  .)


Although that Emacs code is battle-tested, one of the things it does is 
fall back on regular files on platforms where symlinks don't work.


Might be simpler to use a directory sentinel.


The main reason I can think of, not to do this, is that it would make
the locking strategy incompatible with that used by older autom4te;


I would say "don't do that"; just stick with current autom4te.

Re: Future plans for Autotools

[Paul Eggert]

On 1/21/21 8:01 AM, Zack Weinberg wrote:

I know that
at least one person has tried to write a set of GNU Make library files
intended to replace it altogether, but I've never seen anyone *finish*
that project.  I'd very much like to see someone give that another go.


GNU Emacs never used Automake but its developers eventually decided to 
require GNU Make. This has not proved to be a problem in practice, as 
GNU Make is ubiquitous, and Automake features not directly supported by 
GNU Make don't seem to be needed by Emacs builds.


One possible way forward is to have an Autoconf 2 that builds atop GNU 
Make, both as a partial replacement for Automake (which is what Emacs 
does already), and as a way to speed up and simplify configuration.  If 
'configure' were mostly a front end to a GNU Make invocation, it could 
run configuration probes in parallel which would certainly be a win for 
me. And perhaps configuration probes could be written in GNU Make rather 
than m4, which would also be a win because it'd be one less language to 
learn.  (Of course we could continue to support existing m4-based 
probes, run sequentially, as well as letting Automake do its thing for 
people who prefer Automake.)


Whatever way forward is chosen will surely need coordination with 
Gnulib, which has essentially taken over most of the low-level 
system-specific porting tasks that Autoconf used to have. When Emacs 
adopted Gnulib but did not want to use Automake, we had to hack on 
Gnulib to support that; bigger hacks to Gnulib will surely be needed to 
support any of the changes proposed here.

Re: AC_DIAGNOSE not obsolete, please

[Paul Eggert]

On 10/6/20 10:31 AM, Zack Weinberg wrote:

Seems reasonable.  What do you think of the patches below?


Those Autoconf patches look good to me, thanks.

Re: [RFC PATCH 0/6] Work around autoconf/automake warnings skew

[Paul Eggert]

On 9/22/20 1:04 PM, Zack Weinberg wrote:


The main thing I want to discuss before merging these patches is the
location of the new Perl function merge_WARNINGS.  I put it in
ChannelDefs.pm because that is where all the other code relating to
WARNINGS is, but it’s only used in autoreconf, so there’s an argument
for putting it in autoreconf instead, if only so we can modify it in
the future without having to go through automake.


I mildly prefer the way you did it. Thanks for looking into this.

Re: [RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

[Paul Eggert]

On 9/22/20 3:47 PM, Karl Berry wrote:

Zack, the Automake changes look fine to me. Please commit/push at your
convenience, as far as I'm concerned. Thanks!!


They look good to me, too.

Re: Warning category skew between Autoconf and Automake - workaround in autoreconf?

[Paul Eggert]

On 9/10/20 11:48 AM, Zack Weinberg wrote:

I’m wondering whether it would make
sense to merge this distributor’s patch to avoid supplying -Wcross to
automake -- perhaps generalized to arbitrary warning categories.  What
do you think?


Yes, we can't assume that both packages are of the same vintage or have the same 
warnings.


The Autoconf Way would be to probe Automake to see what warnings it supports. 
:-)

Re: problems with "make install" directory permissions

[Paul Eggert]

On 7/27/20 2:24 PM, Karl Berry wrote:

 https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html

I can understand increasing permissions to allow +rx on installation
directories, but why force 755, thus disallowing group writability?
I've never understood this forcing of 755.


I expect it was by analogy with regular files, where are already forced to use 
the equivalent of umask 22 when being installed.


This could have been a decision I made years ago when modifying GNU 'install' - 
I've forgotten the details. (No doubt it was a good decision at the time. :-)

Re: problems with "make install" directory permissions

[Paul Eggert]

[Following up on this thread in bug-bison:
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
]

On 7/26/20 7:09 AM, Frank Heckenbach wrote:

Maybe he can at least fix the permission problem. This should be a
smaller issue (at least compared to parallel configure).


I don't think Zack plans to release a new Automake. He's got enough on his plate 
just doing Autoconf.


That being said, we should be able to fix this particular problem by updating 
Automake master, propagating these fixes into Gnulib, and having Bison use the 
Gnulib versions. I did some of that that by patching Automake master's 
install-sh and mkinstalldirs files, resulting in the attached Gnulib patch which 
I've installed into Gnulib master. Hope this helps.
>From 1990797800153088f32029877f503f3157aad9ed Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 26 Jul 2020 15:17:46 -0700
Subject: [PATCH] autoupdate

---
 build-aux/install-sh| 115 +---
 build-aux/mkinstalldirs |  22 
 2 files changed, 61 insertions(+), 76 deletions(-)

diff --git a/build-aux/install-sh b/build-aux/install-sh
index 20d8b2eae..b34a8fc5a 100755
--- a/build-aux/install-sh
+++ b/build-aux/install-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile
 
-scriptversion=2018-03-11.20; # UTC
+scriptversion=2020-07-26.22; # UTC
 
 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -69,6 +69,10 @@ posix_mkdir=
 # Desired mode of installed file.
 mode=0755
 
+# Create dirs (including intermediate dirs) using mode 755.
+# This is like GNU 'install' as of coreutils 8.32 (2020).
+mkdir_umask=22
+
 chgrpcmd=
 chmodcmd=$chmodprog
 chowncmd=
@@ -301,22 +305,6 @@ do
   if test $dstdir_status != 0; then
 case $posix_mkdir in
   '')
-# Create intermediate dirs using mode 755 as modified by the umask.
-# This is like FreeBSD 'install' as of 1997-10-28.
-umask=`umask`
-case $stripcmd.$umask in
-  # Optimize common cases.
-  *[2367][2367]) mkdir_umask=$umask;;
-  .*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
-
-  *[0-7])
-mkdir_umask=`expr $umask + 22 \
-  - $umask % 100 % 40 + $umask % 20 \
-  - $umask % 10 % 4 + $umask % 2
-`;;
-  *) mkdir_umask=$umask,go-w;;
-esac
-
 # With -d, create the new directory with the user-specified mode.
 # Otherwise, rely on $mkdir_umask.
 if test -n "$dir_arg"; then
@@ -326,52 +314,49 @@ do
 fi
 
 posix_mkdir=false
-case $umask in
-  *[123567][0-7][0-7])
-# POSIX mkdir -p sets u+wx bits regardless of umask, which
-# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
-;;
-  *)
-# Note that $RANDOM variable is not portable (e.g. dash);  Use it
-# here however when possible just to lower collision chance.
-tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
-
-trap 'ret=$?; rmdir "$tmpdir/a/b" "$tmpdir/a" "$tmpdir" 2>/dev/null; exit $ret' 0
-
-# Because "mkdir -p" follows existing symlinks and we likely work
-# directly in world-writeable /tmp, make sure that the '$tmpdir'
-# directory is successfully created first before we actually test
-# 'mkdir -p' feature.
-if (umask $mkdir_umask &&
-$mkdirprog $mkdir_mode "$tmpdir" &&
-exec $mkdirprog $mkdir_mode -p -- "$tmpdir/a/b") >/dev/null 2>&1
-then
-  if test -z "$dir_arg" || {
-   # Check for POSIX incompatibilities with -m.
-   # HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
-   # other-writable bit of parent directory when it shouldn't.
-   # FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
-   test_tmpdir="$tmpdir/a"
-   ls_ld_tmpdir=`ls -ld "$test_tmpdir"`
-   case $ls_ld_tmpdir in
- d-?r-*) different_mode=700;;
- d-?--*) different_mode=755;;
- *) false;;
-   esac &&
-   $mkdirprog -m$different_mode -p -- "$test_tmpdir" && {
- ls_ld_tmpdir_1=`ls -ld "$test_tmpdir"`
- test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
-   }
- }
-  then posix_mkdir=:
-  fi
-  rmdir "$tmpdir/a/b" "$tmpdir/a" "$tmpdir"
-else
-  # Remove any dirs left behind by ancient mkdir implementations.
-

bug#42051: Automake Bug

[Paul Eggert]

Although it's hard to tell from the symptoms, my guess is that it's some sort of 
issue with autom4te calling the wrong version of M4 (or maybe of Perl), or M4 
not being installed in the right place in your VM, or something like that.


Can you specify which version of RHEL you're using, and give a self-contained, 
reproducible test case? That might help track it down.

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

[Paul Eggert]

On 4/13/20 4:21 PM, Harald van Dijk wrote:
For better or worse, FAT is the most universally accepted file system, and for 
that reason it is widely used. It does not even support second precision 
timestamps.


Let's not worry much about that. In practice, little development of 
Automake-using software occurs on FAT file systems, and even if it did those 
file systems are low priority for GNU development.


I just checked, and GNU Make uses high-resolution file timestamps when 
available, and considers a file to be up-to-date if it has exactly the same 
timestamp as its dependency. I suspect that this is because Makefile rules like 
this:


a: b
cp -p b a

would otherwise cause needless work if one ran 'make; make'.

If Automake followed the same rule as GNU Make, we'd at least have the benefit 
of consistency

Re: copyright problem with install-sh, request for clean-room rewrite

[Paul Eggert]

Mathieu Lirzin wrote:

According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.


Thanks for volunteering. Eric, do you think it would save time overall if you 
sent him the part of install-sh that you are sure is *not* problematic, i.e., 
the part that is already copyright by the FSF? That's typical procedure in a 
cleanroom rewrite of anything large; dunno if it's overkill here.

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

[Paul Eggert]

On 11/20/2017 11:44 PM, Bernhard Voelker wrote:

So my question: aren't 3-level version strings allowed by the gnits check
in combination with gnulib's git-version-gen script?  Do we have to 
change

the strictness from gnits to gnu?


I would think so, unless someone takes the time to change Automake so 
that gnits supports the new format of version strings that 
git-version-gen is generating.

[INSTALLED 2/3] install-sh: do not assume / = //

[Paul Eggert]

* lib/install-sh: Do not append / to destination
directory if it already ends in /.  This supports
a destination directory of // on hosts where / and //
are distinct directories, as POSIX allows.
---
 lib/install-sh | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/lib/install-sh b/lib/install-sh
index 0360b79e7..ac159ceda 100755
--- a/lib/install-sh
+++ b/lib/install-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile
 
-scriptversion=2016-01-11.22; # UTC
+scriptversion=2017-09-23.17; # UTC
 
 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -271,15 +271,18 @@ do
 fi
 dst=$dst_arg
 
-# If destination is a directory, append the input filename; won't work
-# if double slashes aren't ignored.
+# If destination is a directory, append the input filename.
 if test -d "$dst"; then
   if test "$is_target_a_directory" = never; then
 echo "$0: $dst_arg: Is a directory" >&2
 exit 1
   fi
   dstdir=$dst
-  dst=$dstdir/`basename "$src"`
+  dstbase=`basename "$src"`
+  case $dst in
+   */) dst=$dst$dstbase;;
+   *)  dst=$dst/$dstbase;;
+  esac
   dstdir_status=0
 else
   dstdir=`dirname "$dst"`
@@ -288,6 +291,11 @@ do
 fi
   fi
 
+  case $dstdir in
+*/) dstdirslash=$dstdir;;
+*)  dstdirslash=$dstdir/;;
+  esac
+
   obsolete_mkdir_used=false
 
   if test $dstdir_status != 0; then
@@ -427,8 +435,8 @@ do
   else
 
 # Make a couple of temp file names in the proper directory.
-dsttmp=$dstdir/_inst.$$_
-rmtmp=$dstdir/_rm.$$_
+dsttmp=${dstdirslash}_inst.$$_
+rmtmp=${dstdirslash}_rm.$$_
 
 # Trap to clean up those temp files at exit.
 trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
-- 
2.13.5

[INSTALLED 1/3] maint: fix two more http: URLs

[Paul Eggert]

* m4/init.m4: Change http: to https: in comments.
---
 m4/init.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/m4/init.m4 b/m4/init.m4
index f788134a1..9024b3aaa 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -87,8 +87,8 @@ AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
 AC_REQUIRE([AC_PROG_MKDIR_P])dnl
 # For better backward compatibility.  To be removed once Automake 1.9.x
 # dies out for good.  For more background, see:
-# 
-# 
+# 
+# 
 AC_SUBST([mkdir_p], ['$(MKDIR_P)'])
 # We need awk for the "check" target (and possibly the TAP driver).  The
 # system "awk" is bad on some platforms.
-- 
2.13.5

[INSTALLED 3/3] maint: update .gitignore

[Paul Eggert]

* .gitignore: Add pre-inst-env, and sort.
---
 .gitignore | 75 +++---
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/.gitignore b/.gitignore
index 56bdce2c6..89e71ec97 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,68 +1,69 @@
-/announcement
-/maintainer/autoconf-*/
-/maintainer/autoconf-*.tar.gz
+/.autom4te.cache
 /ChangeLog
-/aclocal.m4
-/configure
-/Makefile.in
 /Makefile
-/.autom4te.cache
+/Makefile.in
+/aclocal.m4
+/announcement
+/bin/aclocal
+/bin/aclocal-1.*
+/bin/automake
+/bin/automake-1.*
 /config.cache
 /config.log
 /config.status
 /config.status.lineno
+/configure
 /configure.lineno
-/bin/aclocal
-/bin/aclocal-1.*
-/bin/automake
-/bin/automake-1.*
-/runtest
+/contrib/t/*.dir
+/contrib/t/*.log
+/contrib/t/*.trs
 /doc/.dirstamp
-/doc/automake*.info
-/doc/automake*.info-[0-9]
-/doc/automake*.html
-/doc/automake*.dvi
-/doc/automake*.pdf
-/doc/automake*.ps
-/doc/automake*.t2d/
-/doc/automake*.t2p/
-/doc/automake*.1
 /doc/aclocal*.1
-/doc/stamp-vti
-/doc/version.texi
 /doc/amhello-*.tar.gz
 /doc/amhello/Makefile.in
 /doc/amhello/aclocal.m4
+/doc/amhello/compile
 /doc/amhello/config.h.in
 /doc/amhello/config.h.in~
 /doc/amhello/configure
 /doc/amhello/depcomp
-/doc/amhello/compile
 /doc/amhello/install-sh
 /doc/amhello/missing
+/doc/automake*.1
+/doc/automake*.dvi
+/doc/automake*.html
+/doc/automake*.info
+/doc/automake*.info-[0-9]
+/doc/automake*.pdf
+/doc/automake*.ps
+/doc/automake*.t2d/
+/doc/automake*.t2p/
+/doc/stamp-vti
+/doc/version.texi
 /doc/web-manual
 /lib/Automake/Config.pm
-/test-suite.log
-/t/ax/test-defs.sh
-/t/ax/shell-no-trail-bslash
-/t/ax/cc-no-c-o
-/t/testsuite-part.am
-/t/*-w.tap
+/maintainer/autoconf-*.tar.gz
+/maintainer/autoconf-*/
+/pre-inst-env
+/runtest
 /t/*-w.sh
-/t/depcomp-*.tap
+/t/*-w.tap
 /t/*.dir
 /t/*.log
 /t/*.trs
-/contrib/t/*.dir
-/contrib/t/*.log
-/contrib/t/*.trs
-/t/pm/*.log
-/t/pm/*.trs
+/t/ax/cc-no-c-o
+/t/ax/shell-no-trail-bslash
+/t/ax/test-defs.sh
+/t/depcomp-*.tap
 /t/perf/*.log
 /t/perf/*.trs
+/t/pm/*.log
+/t/pm/*.trs
+/t/testsuite-part.am
+/test-suite.log
+TAGS
 cscope.files
 cscope.in.out
 cscope.out
 cscope.po.out
 tags
-TAGS
-- 
2.13.5

Re: bug#20314: [PATCH] Make output of mdate-sh deterministic

[Paul Eggert]

On 09/22/2017 02:57 AM, Bruno Haible wrote:

Gnulib also supports MSVC, which interprets the TZ environment variable in its
own way [1][2]. From this doc and from POSIX [3], it looks to me that
   UTC0
   GMT0
   GMT+0
   GMT-0
would all be equivalent and portable. Can you confirm this?


All of them would use UTC (the first one with the abbreviation "UTC", 
the others with "GMT"). Other variants would work as well, e.g., 
"UTC-00:00:00". I usually use "UTC0" as it's simplest and most 
technically correct (GMT stopped being standardized many years ago).

Re: bug#20314: [PATCH] Make output of mdate-sh deterministic

[Paul Eggert]

Unfortunately that patch to Automake's mdate-sh is not portable, as TZ='UTC' is 
not a portable setting for the TZ environment variable. POSIX says you're 
supposed to use something like TZ='UTC0' instead. Although TZ='UTC' works when 
glibc is used, this is not necessarily true on other POSIX platforms.


I noticed this problem when recent Automake changes were merged into Gnulib, and 
installed the attached patch to the Automake master branch to fix this. Please 
review any other patches you may be using for reproducible builds, and fix them 
to use TZ='UTC0' instead of TZ='UTC'. Thanks.


For reference, here's the POSIX spec for TZ:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

and look for "TZ".
From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 21 Sep 2017 20:08:48 -0700
Subject: [PATCH] * lib/mdate.sh (TZ): Use portable setting.

---
 lib/mdate-sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/mdate-sh b/lib/mdate-sh
index 6dd5b21e7..34de97554 100755
--- a/lib/mdate-sh
+++ b/lib/mdate-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Get modification time of a file or directory and pretty-print it.
 
-scriptversion=2017-09-19.11; # UTC
+scriptversion=2017-09-22.02; # UTC
 
 # Copyright (C) 1995-2017 Free Software Foundation, Inc.
 # written by Ulrich Drepper <drep...@gnu.ai.mit.edu>, June 1995
@@ -75,7 +75,7 @@ LC_TIME=C
 export LC_TIME
 
 # Use UTC to get reproducible result.
-TZ=UTC
+TZ=UTC0
 export TZ
 
 # GNU ls changes its time format in response to the TIME_STYLE
-- 
2.13.5

bug#20314: [PATCH] Make output of mdate-sh deterministic

[Paul Eggert]

Unfortunately that patch to Automake's mdate-sh is not portable, as TZ='UTC' is 
not a portable setting for the TZ environment variable. POSIX says you're 
supposed to use something like TZ='UTC0' instead. Although TZ='UTC' works when 
glibc is used, this is not necessarily true on other POSIX platforms.


I noticed this problem when recent Automake changes were merged into Gnulib, and 
installed the attached patch to the Automake master branch to fix this. Please 
review any other patches you may be using for reproducible builds, and fix them 
to use TZ='UTC0' instead of TZ='UTC'. Thanks.


For reference, here's the POSIX spec for TZ:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

and look for "TZ".
From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Thu, 21 Sep 2017 20:08:48 -0700
Subject: [PATCH] * lib/mdate.sh (TZ): Use portable setting.

---
 lib/mdate-sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/mdate-sh b/lib/mdate-sh
index 6dd5b21e7..34de97554 100755
--- a/lib/mdate-sh
+++ b/lib/mdate-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Get modification time of a file or directory and pretty-print it.
 
-scriptversion=2017-09-19.11; # UTC
+scriptversion=2017-09-22.02; # UTC
 
 # Copyright (C) 1995-2017 Free Software Foundation, Inc.
 # written by Ulrich Drepper <drep...@gnu.ai.mit.edu>, June 1995
@@ -75,7 +75,7 @@ LC_TIME=C
 export LC_TIME
 
 # Use UTC to get reproducible result.
-TZ=UTC
+TZ=UTC0
 export TZ
 
 # GNU ls changes its time format in response to the TIME_STYLE
-- 
2.13.5

Re: FTP,HTTP → HTTPS in Automake doc and code

[Paul Eggert]

Mathieu Lirzin wrote:

IMO it is important that
reflects that change too.  AIUI this page serves as a model for GPL
license notices.


Yes, that would be good. Unfortunately I don't know who's in charge of that URL.

FTP,HTTP → HTTPS in Automake doc and code

[Paul Eggert]

I installed into Automake 'master' a patch to prefer https: URLs to ftp: and 
http: URLs. It's a long patch so I won't bore the mailing list with it. Details 
and justification are here:


https://git.savannah.gnu.org/cgit/automake.git/commit/?id=199e7a445040270fa5ef67623c56cde40d765199

Re: [PATCH v3] new option: object-shortname

[Paul Eggert]

On 12/22/2016 06:38 AM, Thomas Martitz wrote:
this is one more attempt to get my patch reviewed. Can I assist in any 
way? 


Well, what we really need is an Automake maintainer, to do this sort of 
review work. Is that something you'd be willing to do (and be qualified 
for)? It's not a job to be undertaken lightly, of course.

Re: [PATCH v3] new option: object-shortname

[Paul Eggert]

Thomas Martitz wrote:

I thought you'd review and merge.


It might be me at some point. Just not today, I'm afraid.

Re: [PATCH v3] new option: object-shortname

[Paul Eggert]

Thomas Martitz wrote:

Please tell me if there's anything left for me to do?


Not that I know of; someone needs to free up enough cycles to review it, that's 
all.

Re: bug#22702: [bug-grep] grep-2.23 build feedback

[Paul Eggert]

Jim Meyering wrote:

I actually wrote a patch to fix the automake bug that led to this,
but did not find the time to write a stand-alone test case.
Today, I wrote the commit log entry and am attaching the
incomplete diff (no NEWS and no test) here, in case someone
wants to help move this along before I find time.


Thanks, I installed that patch into automake (Savannah micro branch).

This should fix Bug#21815 so I'll close that bug report while I'm at it.

Re: [PATCH v2] new option: object-shortname

[Paul Eggert]

Some minor comments:


+  - This option affects the file name automake uses for object files.
+
+Enabling the option shortens the file name such that the prefix
+derived (after canonicalization) from the path is not included. For
+instance, it is always foo-foo.o regardless of the path leading to the
+source file.
+
+It does not change the directory where these object files will be placed.
+Thus, it is recommended to combine this option with subdir-objects.
+
+  - Please read the corresponding manual entry for an extensive description.


Please make the NEWS item a bit shorter. No need for the last sentence, for 
example.


+   if (option 'object-shortname') {


Please use the same style for indenting that the code already uses, with the { 
on the next line and indented by two columns.



+   # If object-shortname is enabled the object's filename 
shall not contain the parts


Please keep everything within 80 columns.


+If this option is specified, then object names constructed by automake are


Capitalize "automake" when used this way.


+therefore ommitting the canonicalized path (@pxref{Canonicalization}). The


misspelled "omitting". Two spaces after sentence-ending periods.


+effect is particularly visible if you use Makefile fragment inclusion feature


@file{Makefile}


+foo}. However, it also works flawlessly if a Makefile fragment is


Omit "flawlessly".


+This is best combined with @option{subdir-objects} because it file name
+conflicts become more likely.


Can't parse this.


+The rationale for this option is to allow a setup where there is a top-level
+@file{Makefile.am} which includes fragments from subdirectories, which also
+generate a Makefile.


Is one Makefile being generated, or many? It's not clear from the sentence.

Re: [PATCH] new option: object-shortname

[Paul Eggert]

Have you looked at the similar change that is planned for Automake 1.16? To 
build that, you can do this:


git clone -b minor git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap.sh
./configure --prefix=/your/favorite/directory
make

Assuming your needs aren't satisfied already by 1.16's plans, please look into 
folding your code into draft 1.16.


I would either not bother with the paranoid check, or have Automake fail if the 
paranoid check fails.


The main thing missing, though, is the documentation. It needs explanation in 
the manual (doc/automake.texi), probably with your use case. Plus, NEWS needs 
updating.


One more thing -- I assume you're OK with assigning copyright to the FSF for 
your change? If so, I can get the ball rolling on that.


Thanks.

bug#21219: automake: m4/python.m4: support python3.4 and python3.5

[Paul Eggert]

On 04/22/2016 06:46 AM, Thomas Klausner wrote:

Thanks. I don't see the commit onhttp://git.savannah.gnu.org/cgit/automake.git  
yet though?


http://git.savannah.gnu.org/cgit/automake.git/log/?h=micro



We can also close my bug report 21219 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21219).
  Thomas


OK, done.

[PATCH] maint: port time-stamp-time-zone to strict POSIX

[Paul Eggert]

Set time-stamp-time-zone to "UTC0", not to "UTC", as POSIX defines
TZ="UTC0" not TZ="UTC".
---
 contrib/tap-driver.pl | 2 +-
 lib/compile   | 4 ++--
 lib/depcomp   | 4 ++--
 lib/install-sh| 4 ++--
 lib/mdate-sh  | 4 ++--
 lib/missing   | 4 ++--
 lib/mkinstalldirs | 4 ++--
 lib/py-compile| 4 ++--
 lib/tap-driver.sh | 2 +-
 lib/test-driver   | 4 ++--
 lib/ylwrap| 4 ++--
 11 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/contrib/tap-driver.pl b/contrib/tap-driver.pl
index ee73b99..e9caa8e 100755
--- a/contrib/tap-driver.pl
+++ b/contrib/tap-driver.pl
@@ -558,6 +558,6 @@ main @ARGV;
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "my $VERSION = "
 # time-stamp-format: "'%:y-%02m-%02d.%02H'"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/compile b/lib/compile
index dc7a6e7..4bfd30c 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand '-c -o'.
 
-scriptversion=2015-11-24.11; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # Copyright (C) 1999-2015 Free Software Foundation, Inc.
 # Written by Tom Tromey .
@@ -343,6 +343,6 @@ exit $ret
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/depcomp b/lib/depcomp
index 2260d5d..f60d4b8 100755
--- a/lib/depcomp
+++ b/lib/depcomp
@@ -1,7 +1,7 @@
 #! /bin/sh
 # depcomp - compile a program generating dependencies as side-effects
 
-scriptversion=2013-05-30.07; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # Copyright (C) 1999-2015 Free Software Foundation, Inc.
 
@@ -786,6 +786,6 @@ exit 0
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/install-sh b/lib/install-sh
index 0b0fdcb..0360b79 100755
--- a/lib/install-sh
+++ b/lib/install-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile
 
-scriptversion=2013-12-25.23; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -496,6 +496,6 @@ done
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/mdate-sh b/lib/mdate-sh
index b793600..6022eff 100755
--- a/lib/mdate-sh
+++ b/lib/mdate-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Get modification time of a file or directory and pretty-print it.
 
-scriptversion=2010-08-21.06; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # Copyright (C) 1995-2015 Free Software Foundation, Inc.
 # written by Ulrich Drepper , June 1995
@@ -219,6 +219,6 @@ echo $day $month $year
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/missing b/lib/missing
index 3af2828..594918c 100755
--- a/lib/missing
+++ b/lib/missing
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Common wrapper for a few potentially missing GNU programs.
 
-scriptversion=2013-10-28.13; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # Copyright (C) 1996-2015 Free Software Foundation, Inc.
 # Originally written by Fran,cois Pinard , 1996.
@@ -210,6 +210,6 @@ exit $st
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/mkinstalldirs b/lib/mkinstalldirs
index 55d537f..a31ce6d 100755
--- a/lib/mkinstalldirs
+++ b/lib/mkinstalldirs
@@ -1,7 +1,7 @@
 #! /bin/sh
 # mkinstalldirs --- make directory hierarchy
 
-scriptversion=2009-04-28.21; # UTC
+scriptversion=2016-01-11.22; # UTC
 
 # Original author: Noah Friedman 
 # Created: 1993-05-16
@@ -157,6 +157,6 @@ exit $errstatus
 # eval: (add-hook 'write-file-hooks 'time-stamp)
 # time-stamp-start: "scriptversion="
 # time-stamp-format: "%:y-%02m-%02d.%02H"
-# time-stamp-time-zone: "UTC"
+# time-stamp-time-zone: "UTC0"
 # time-stamp-end: "; # UTC"
 # End:
diff --git a/lib/py-compile b/lib/py-compile
index 382e083..b712837 100755
--- a/lib/py-compile
+++ b/lib/py-compile
@@ -1,7 +1,7 @@
 #!/bin/sh
 # py-compile - Compile a Python program
 
-scriptversion=2011-06-08.12; # UTC

bug#20132: [PROPOSED PATCH] autoconf: port better to future gzip

[Paul Eggert]

* lib/am/distdir.am (dist-gzip, dist-shar, distcheck):
Port better to future versions of gzip, which are planned to
deprecate the GZIP environment variable.
---
 lib/am/distdir.am | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index d4dd8cc..87c6730 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -309,6 +309,16 @@ endif %?TOPDIR_P%
 ## We order DIST_TARGETS by expected duration of the compressors,
 ## slowest first, for better parallelism in make dist.  Do not
 ## reorder DIST_ARCHIVES, users may expect gzip to be first.
+##
+## Traditionally, gzip prepended the contents of the GZIP environment
+## variable to its arguments, and the commands below formerly used
+## this by invoking 'GZIP=$(GZIP_ENV) gzip'.  The GZIP environment
+## variable is now considered to be obsolescent, so the commands below
+## now use 'eval GZIP= gzip $(GZIP_ENV)' instead; this should work
+## with both older and newer gzip implementations.  The 'eval' is to
+## support makefile assignments like 'GZIP_ENV = -9 -n' that quote
+## the GZIP_ENV right-hand side because that was needed with the
+## former invocation pattern.
 
 if %?TOPDIR_P%
 
@@ -316,7 +326,7 @@ if %?TOPDIR_P%
 GZIP_ENV = --best
 .PHONY: dist-gzip
 dist-gzip: distdir
-   tardir=$(distdir)  $(am__tar) | GZIP=$(GZIP_ENV) gzip -c 
$(distdir).tar.gz
+   tardir=$(distdir)  $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c 
$(distdir).tar.gz
$(am__post_remove_distdir)
 
 ?BZIP2?DIST_ARCHIVES += $(distdir).tar.bz2
@@ -352,7 +362,7 @@ dist-shar: distdir
@echo WARNING: Support for shar distribution archives 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
+   shar $(distdir) | eval GZIP= gzip $(GZIP_ENV) -c $(distdir).shar.gz
$(am__post_remove_distdir)
 
 ?ZIP?DIST_ARCHIVES += $(distdir).zip
@@ -412,7 +422,7 @@ endif %?SUBDIRS%
 distcheck: dist
case '$(DIST_ARCHIVES)' in \
*.tar.gz*) \
- GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\
+ eval GZIP= gzip $(GZIP_ENV) -dc $(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \
  bzip2 -dc $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lz*) \
@@ -422,7 +432,7 @@ distcheck: dist
*.tar.Z*) \
  uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \
- GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\
+ eval GZIP= gzip $(GZIP_ENV) -dc $(distdir).shar.gz | unshar ;;\
*.zip*) \
  unzip $(distdir).zip ;;\
esac
-- 
2.1.0

bug#19616: [Bug-tar] dist tarball contains hardlinks

[Paul Eggert]

Dimitrios Apostolou wrote:

But when the tarball is extracted, two files with same inode are created, which
is kind of unexpected behaviour - at least for me


Other utilities have similar behavior (e.g., ls, cp, du), in that they pretend 
the symlink isn't there and behave as if the pointed-to inode is there directly. 
 Tar's current behavior is compatible with these other utilities, whereas its 
old behavior was incompatible.

bug#19616: [Bug-tar] dist tarball contains hardlinks

[Paul Eggert]

Dimitrios Apostolou wrote:

Why is such behaviour desirable?


It's more logical, since it causes tar to behave as if the symlink were not 
there, and the pointed-to file was there instead.


Using -hard-dereference bloats the tar image, but if that's a price you're 
willing to pay then you have a solution to the problem.

bug#18301: texi-vers.am: Problem with parallel builds due to vti.tmp

[Paul Eggert]

Thanks, I installed the attached patch, which has the more-usual 
approach of a uniquely-named temporary.
From 28b4fdb0ea4c540f1b7bcb90675e365e3aa11beb Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sat, 23 Aug 2014 07:55:28 -0700
Subject: [PATCH] build: fix race in parallel builds

Reported by Friedrich Beckmann in: http://bugs.gnu.org/18301
* lib/am/texi-vers.am (?DIRSTAMP?): Put the process-ID into the
temporary file name.  Use a similar temporary in the source dir.
---
 lib/am/texi-vers.am | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/am/texi-vers.am b/lib/am/texi-vers.am
index bddf382..e98bb82 100644
--- a/lib/am/texi-vers.am
+++ b/lib/am/texi-vers.am
@@ -31,25 +31,25 @@ DIST_COMMON += %VTEXI% %STAMPVTI%
 ## %STAMPVTI% is distributed and %DIRSTAMP% isn't: a distributed file
 ## should never be dependent upon a non-distributed built file.
 ## Therefore we ensure that %DIRSTAMP% exists in the rule.
+## Use cp + mv so that the update of %VTEXI% is atomic even if
+## the source directory is on a different file system.
 ?DIRSTAMP? @test -f %DIRSTAMP% || $(MAKE) $(AM_MAKEFLAGS) %DIRSTAMP%
@(dir=.; test -f ./%TEXI% || dir=$(srcdir); \
set `$(SHELL) %MDDIR%mdate-sh $$dir/%TEXI%`; \
echo @set UPDATED $$1 $$2 $$3; \
echo @set UPDATED-MONTH $$2 $$3; \
echo @set EDITION $(VERSION); \
-   echo @set VERSION $(VERSION))  %VTI%.tmp
-## Use cp and rm here because some older mvs can't move across
-## filesystems.  Furthermore, GNU mv in the AmigaDOS environment
-## can't handle this.
-   @cmp -s %VTI%.tmp %VTEXI% \
- || (echo Updating %VTEXI%; \
- cp %VTI%.tmp %VTEXI%)
-   -@rm -f %VTI%.tmp
+   echo @set VERSION $(VERSION))  %VTI%.tmp  \
+   (cmp -s %VTI%.tmp %VTEXI% \
+ || (echo Updating %VTEXI%  \
+ cp %VTI%.tmp %VTEXI%.tmp  \
+ mv %VTEXI%.tmp %VTEXI%))  \
+   rm -f %VTI%.tmp %VTEXI%.
@cp %VTEXI% $@
 
 mostlyclean-am: mostlyclean-%VTI%
 mostlyclean-%VTI%:
-   -rm -f %VTI%.tmp
+   -rm -f %VTI%.tmp* %VTEXI%.tmp*
 
 maintainer-clean-am: maintainer-clean-%VTI%
 maintainer-clean-%VTI%:
-- 
1.9.3

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

[Paul Eggert]

Stefano Lattarini wrote:

please push (to the 'micro' branch) and close this bug
report once you're done


Thanks, done.

Re: bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

[Paul Eggert]

Stefano Lattarini wrote:

please push (to the 'micro' branch) and close this bug
report once you're done


Thanks, done.

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

[Paul Eggert]

* 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
 
--

1.8.3.1

Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/16/13 04:46, Stefano Lattarini wrote:
 Makes sense.  Should I try to implement something along these lines (might
 take a few days), or are you planning to do that yourself (in which case
 I'll avoid the duplicated efforts)?

I wasn't planning on doing that, so please go ahead.

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/14/13 02:24, Stefano Lattarini wrote:
 Autoconfers, WDYT?

I think I'm lost.  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
is a long thread.

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
  or 'clang') supports -c -o together.  Why?  If the user has a
  broken base vendor compiler, but has installed a better one (say
  GCC), why should he still be penalized?

I don't know.  It's been that way for two decades or so, for no
reason that I can see.
 
   2. The fact the cache variable used by the test is based on the
  contents of the $CC expansion seems fragile and confusing.  AFICS,
  none of the other cache variables referring to check on the
  selected C compiler has this property -- so why should this one?

Again, no good reason that I can see.

 So, my question is: could any of this semantics be improved in the
 obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
 macro for backward-compatibility considerations (and risking to introduce
 incompatibilities a last minute change might indeed not be a good idea),

We could have the change take effect only if some other macro is invoked,
indicating that the user wants the new behavior.  That should be safe.
The default behavior can be the old behavior for now, with the intent that
this will eventually change to the new behavior.

Re: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/14/13 02:24, Stefano Lattarini wrote:
 Autoconfers, WDYT?

I think I'm lost.  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
is a long thread.

Re: Cleaning up AC_PROG_CC_C_O semantics

[Paul Eggert]

On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
   1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
  or 'clang') supports -c -o together.  Why?  If the user has a
  broken base vendor compiler, but has installed a better one (say
  GCC), why should he still be penalized?

I don't know.  It's been that way for two decades or so, for no
reason that I can see.
 
   2. The fact the cache variable used by the test is based on the
  contents of the $CC expansion seems fragile and confusing.  AFICS,
  none of the other cache variables referring to check on the
  selected C compiler has this property -- so why should this one?

Again, no good reason that I can see.

 So, my question is: could any of this semantics be improved in the
 obvious way in Autoconf 2.70?  If this is not doable in the pre-existing
 macro for backward-compatibility considerations (and risking to introduce
 incompatibilities a last minute change might indeed not be a good idea),

We could have the change take effect only if some other macro is invoked,
indicating that the user wants the new behavior.  That should be safe.
The default behavior can be the old behavior for now, with the intent that
this will eventually change to the new behavior.

bug#12578: depcomp typo informations

[Paul Eggert]

On 10/14/2012 02:49 AM, Stefano Lattarini wrote:
 However, for the future, might I ask you to provide complete patches, even
 for trivial fixlets like this one?  That would make the workflow easier for
 me.

Sure.  Even less work for you (and for me) would be if I simply
applied the patches.

bug#12578: depcomp typo informations

[Paul Eggert]

There is no word informations in English.
I found this typo while spell-checking Emacs,
and want to fix the bug upstream, in Automake.

diff --git a/lib/depcomp b/lib/depcomp
index 0544c68..ee84bf2 100755
--- a/lib/depcomp
+++ b/lib/depcomp
@@ -108,7 +108,7 @@ if test $depmode = msvc7msys; then
 fi
 
 if test $depmode = xlc; then
-   # IBM C/C++ Compilers xlc/xlC can output gcc-like dependency informations.
+   # IBM C/C++ Compilers xlc/xlC can output gcc-like dependency information.
gccflag=-qmakedep=gcc,-MF
depmode=gcc
 fi

Re: Python macros

[Paul Eggert]

My kneejerk reaction is that Python would be a good language
for Autoconf to deal with.  The hard part would probably
be writing the documentation -- is that something you
could do?  The idea would be to come up with a patch
to the Autoconf sources.

Re: [FYI] {master} maint: assume 'test -x' is portable

[Paul Eggert]

It's been Quite Some Time since I've had to deal with
4.3BSD, or any host with a test -x problem, so I suggest
the following patch to the Autoconf manual:

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 607d8dc..443ec07 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -18125,9 +18125,9 @@ It is safe to use @samp{!} as a @command{test} 
operator.  For example,
 To enable @command{configure} scripts to support cross-compilation, they
 shouldn't do anything that tests features of the build system instead of
 the host system.  But occasionally you may find it necessary to check
-whether some arbitrary file exists.  To do so, use @samp{test -f} or
-@samp{test -r}.  Do not use @samp{test -x}, because 4.3BSD does not
-have it.  Do not use @samp{test -e} either, because Solaris @command{/bin/sh}
+whether some arbitrary file exists.  To do so, use @samp{test -f},
+@samp{test -r}, or @samp{test -x}.  Do not use @samp{test -e},
+because Solaris @command{/bin/sh}
 lacks it.  To test for symbolic links on systems that have them, use
 @samp{test -h} rather than @samp{test -L}; either form conforms to
 Posix 1003.1-2001, but older shells like Solaris 8
@@ -26320,8 +26320,8 @@ Unix M4 started to dump core because of the length of 
the
 macros that Autoconf defined, and several bugs showed up in GNU
 M4 as well.  Eventually, we realized that we needed to use some
 features that only GNU M4 has.  4.3BSD M4, in
-particular, has an impoverished set of builtin macros; the System V
-version is better, but still doesn't provide everything we need.
+particular, had an impoverished set of builtin macros; the System V
+version was better, but still didn't provide everything we need.
 
 More development occurred as people put Autoconf under more stresses
 (and to uses I hadn't anticipated).  Karl Berry added checks for X11.

bug#10443: [PATCH] Quote 'like this', not `like this'.

[Paul Eggert]

This proposed patch follows up on recent changes to the GNU coding
standards.  They now suggest that we should quote 'like this' or
like this instead of `like this'; see
http://www.gnu.org/prep/standards/html_node/Quote-Characters.html.

Gnulib is being changed accordingly, and Gnulib imports some files
directly from Automake master, so here is a proposed patch to Automake
master so that these files use the straight-up style.  This patch
affects only commentary and quoting in diagnostics.

From f78c4d9a1fc2705badae4ce4ebf46d5d1c8209e0 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Fri, 6 Jan 2012 00:24:26 -0800
Subject: [PATCH] Quote 'like this', not `like this'.

---
 lib/ar-lib|2 +-
 lib/compile   |   22 ++--
 lib/depcomp   |   40 ++--
 lib/elisp-comp|8 ++--
 lib/gnupload  |   12 +++---
 lib/install-sh|   10 +++---
 lib/mdate-sh  |   12 +++---
 lib/missing   |  102 ++--
 lib/mkinstalldirs |4 +-
 lib/ylwrap|8 ++--
 10 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/lib/ar-lib b/lib/ar-lib
index 1a1dbd0..85d028f 100755
--- a/lib/ar-lib
+++ b/lib/ar-lib
@@ -98,7 +98,7 @@ func_at_file ()
 
 case $1 in
   '')
- func_error no command.  Try \`$0 --help' for more information.
+ func_error no command.  Try '$0 --help' for more information.
  ;;
   -h | --h*)
 cat EOF
diff --git a/lib/compile b/lib/compile
index b246777..b1f4749 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,5 +1,5 @@
 #! /bin/sh
-# Wrapper for compilers which do not understand `-c -o'.
+# Wrapper for compilers which do not understand '-c -o'.
 
 scriptversion=2012-01-04.17; # UTC
 
@@ -94,7 +94,7 @@ func_cl_wrapper ()
 else
   case $1 in
-o)
- # configure might choose to run compile as `compile cc -o foo foo.c'.
+ # configure might choose to run compile as 'compile cc -o foo foo.c'.
  eat=1
  case $2 in
*.o | *.[oO][bB][jJ])
@@ -196,19 +196,19 @@ eat=
 
 case $1 in
   '')
- echo $0: No command.  Try \`$0 --help' for more information. 12
+ echo $0: No command.  Try '$0 --help' for more information. 12
  exit 1;
  ;;
   -h | --h*)
 cat \EOF
 Usage: compile [--help] [--version] PROGRAM [ARGS]
 
-Wrapper for compilers which do not understand `-c -o'.
-Remove `-o dest.o' from ARGS, run PROGRAM with the remaining
+Wrapper for compilers which do not understand '-c -o'.
+Remove '-o dest.o' from ARGS, run PROGRAM with the remaining
 arguments, and rename the output as expected.
 
 If you are trying to build a whole package this is not the
-right script to run: please start by reading the file `INSTALL'.
+right script to run: please start by reading the file 'INSTALL'.
 
 Report bugs to bug-automake@gnu.org.
 EOF
@@ -233,8 +233,8 @@ do
   else
 case $1 in
   -o)
-   # configure might choose to run compile as `compile cc -o foo foo.c'.
-   # So we strip `-o arg' only if arg is an object.
+   # configure might choose to run compile as 'compile cc -o foo foo.c'.
+   # So we strip '-o arg' only if arg is an object.
eat=1
case $2 in
  *.o | *.obj)
@@ -261,10 +261,10 @@ do
 done
 
 if test -z $ofile || test -z $cfile; then
-  # If no `-o' option was seen then we might have been invoked from a
+  # If no '-o' option was seen then we might have been invoked from a
   # pattern rule where we don't need one.  That is ok -- this is a
   # normal compilation that the losing compiler can handle.  If no
-  # `.c' file was seen then we are probably linking.  That is also
+  # '.c' file was seen then we are probably linking.  That is also
   # ok.
   exec $@
 fi
@@ -273,7 +273,7 @@ fi
 cofile=`echo $cfile | sed 's|^.*[\\/]||; s|^[a-zA-Z]:||; s/\.c$/.o/'`
 
 # Create the lock directory.
-# Note: use `[/\\:.-]' here to ensure that we don't use the same name
+# Note: use '[/\\:.-]' here to ensure that we don't use the same name
 # that we are using for the .o file.  Also, base the name on the expected
 # object file name, since that is what matters with a parallel build.
 lockdir=`echo $cofile | sed -e 's|[/\\:.-]|_|g'`.d
diff --git a/lib/depcomp b/lib/depcomp
index bd0ac08..ff4e08f 100755
--- a/lib/depcomp
+++ b/lib/depcomp
@@ -28,7 +28,7 @@ scriptversion=2011-12-04.11; # UTC
 
 case $1 in
   '')
- echo $0: No command.  Try \`$0 --help' for more information. 12
+ echo $0: No command.  Try '$0 --help' for more information. 12
  exit 1;
  ;;
   -h | --h*)
@@ -40,8 +40,8 @@ as side-effects.
 
 Environment variables:
   depmode Dependency tracking mode.
-  source  Source file read by `PROGRAMS ARGS'.
-  object  Object file output by `PROGRAMS ARGS'.
+  source  Source file read by 'PROGRAMS ARGS'.
+  object  Object file output by 'PROGRAMS ARGS'.
   DEPDIR  directory where to store dependencies.
   depfile Dependency file

bug#10443: [PATCH] Quote 'like this', not `like this'.

[Paul Eggert]

On 01/06/12 02:00, Stefano Lattarini wrote:

 please send patches that don't fix any existing bug to the automake-patches

Sorry, I'll try to remember that.

 assuming you have already re-run the whole testsuite
 with your changes applied, which you have, right?)

Yes, I have now, on a Fedora 15 x86-64 host.  The changes don't affect
the testsuite results (the tests that fail after the change also failed
before the change).  The failing tests are:

FAIL: depmod.tap 50 - tru64 [long VPATH] make  remake
FAIL: depmod.tap 84 - tru64 [absolute VPATH] make  remake
FAIL: lzma.test
FAIL: tap-summary-color.test

I can send more details if you like.

 the patch is OK, modulo
 two minor nits.  Feel free to push to master once they have been addressed.

Thanks, I fixed those and pushed.

bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines

[Paul Eggert]

On 01/05/12 06:07, Stefano Lattarini wrote:
 Which sort of thing exactly?  I could find only one place which suffers
 of the problem you've pointed out, i.e., the `recheck recheck-html' rules
 in lib/am/check.am.  Am I missing something?

Sorry, that appears to have been a miscount on my part:
I was counting some files that Automake generates for itself
while building.  In Automake source there are only two instances,
which your patch caught: the 'recheck recheck-html' rule and
the 'check-TESTS' rule (the latter is what actually triggered
the problem with coreutils).  So this should be OK.

Thanks for the quick fixes, by the way!

bug#10436: bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes

[Paul Eggert]

I pushed the following doc fix into Autoconf, so that these two portability
issues are documented there.  It turns out that the second issue
is actually due to an old Bash bug -- it's not Solaris-specific.

From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 5 Jan 2012 11:00:45 -0800
Subject: [PATCH 1/2] doc: clarify sed buffer limit

* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
---
 ChangeLog |6 ++
 doc/autoconf.texi |5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 30312be..238c09f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-01-05  Paul Eggert  egg...@cs.ucla.edu
+
+   doc: clarify sed buffer limit
+   * doc/autoconf.texi (Limitations of Usual Tools):
+   That 4000-byte limit applies to output and internal buffers, too.
+
 2012-01-03  Paul Eggert  egg...@cs.ucla.edu
 
maint: update copyright year
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 72ff7f8..ea2419b 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19256,8 +19256,9 @@ $ @kbd{echo a | sed 's/x/x/;;s/x/x/'}
 sed: 1: s/x/x/;;s/x/x/: invalid command code ;
 @end example
 
-Input should not have unreasonably long lines, since some @command{sed}
-implementations have an input buffer limited to 4000 bytes.  Likewise,
+Some @command{sed} implementations have a buffer limited to 4000 bytes,
+and this limits the size of input lines, output lines, and internal
+buffers that can be processed portably.  Likewise,
 not all @command{sed} implementations can handle embedded @code{NUL} or
 a missing trailing newline.
 
-- 
1.7.6.5


From 0445b4ad121e6356f409833dec3678ae613e1d08 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 5 Jan 2012 12:32:12 -0800
Subject: [PATCH 2/2] doc: mention Bash 2.03 bug with backslash-newline

* doc/autoconf.texi (Invoking the Shell): New section.
(Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
Mention problem with Bash 2.03.
---
 ChangeLog |5 
 doc/autoconf.texi |   56 +---
 2 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 238c09f..69df405 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2012-01-05  Paul Eggert  egg...@cs.ucla.edu
 
+   doc: mention Bash 2.03 bug with backslash-newline
+   * doc/autoconf.texi (Invoking the Shell): New section.
+   (Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
+   Mention problem with Bash 2.03.
+
doc: clarify sed buffer limit
* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ea2419b..5c3feef 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -501,6 +501,7 @@ Dependencies Between Macros
 Portable Shell Programming
 
 * Shellology::  A zoology of shells
+* Invoking the Shell::  Invoking the shell as a command
 * Here-Documents::  Quirks and tricks
 * File Descriptors::FDs and redirections
 * Signal Handling:: Shells, signals, and headaches
@@ -520,7 +521,7 @@ Portable Make Programming
 * $ in Ordinary Make Rules::   $ in ordinary rules
 * Failure in Make Rules::   Failing portably in rules
 * Special Chars in Names::  Special Characters in Macro Names
-* Backslash-Newline-Newline::   Empty last lines in macro definitions
+* Backslash-Newline-Empty:: Empty lines after backslash-newline
 * Backslash-Newline Comments::  Spanning comments across line boundaries
 * Long Lines in Makefiles:: Line length limitations
 * Macros and Submakes:: @code{make macro=value} and submakes
@@ -15067,6 +15068,7 @@ subset described above, is fairly portable nowadays.  
Also please see
 
 @menu
 * Shellology::  A zoology of shells
+* Invoking the Shell::  Invoking the shell as a command
 * Here-Documents::  Quirks and tricks
 * File Descriptors::FDs and redirections
 * Signal Handling:: Shells, signals, and headaches
@@ -15205,6 +15207,28 @@ The default Mac OS X @command{sh} was originally Zsh; 
it was changed to
 Bash in Mac OS X 10.2.
 @end table
 
+@node Invoking the Shell
+@section Invoking the Shell
+@cindex invoking the shell
+@cindex shell invocation
+
+Bash 2.03 has a bug when invoked with the @option{-c} option: if the
+option-argument ends in backslash-newline, Bash incorrectly reports a
+syntax error.  The problem does not occur if a character follows the
+backslash:
+
+@example
+$ @kbd{$ bash -c 'echo foo \}
+ @kbd{'}
+bash: -c: line 2: syntax error: unexpected end of file
+$ @kbd{bash -c 'echo foo \}
+ @kbd{ '}
+foo
+@end example
+
+@noindent
+@xref{Backslash-Newline

Re: bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes

[Paul Eggert]

I pushed the following doc fix into Autoconf, so that these two portability
issues are documented there.  It turns out that the second issue
is actually due to an old Bash bug -- it's not Solaris-specific.

From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 5 Jan 2012 11:00:45 -0800
Subject: [PATCH 1/2] doc: clarify sed buffer limit

* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
---
 ChangeLog |6 ++
 doc/autoconf.texi |5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 30312be..238c09f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-01-05  Paul Eggert  egg...@cs.ucla.edu
+
+   doc: clarify sed buffer limit
+   * doc/autoconf.texi (Limitations of Usual Tools):
+   That 4000-byte limit applies to output and internal buffers, too.
+
 2012-01-03  Paul Eggert  egg...@cs.ucla.edu
 
maint: update copyright year
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 72ff7f8..ea2419b 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19256,8 +19256,9 @@ $ @kbd{echo a | sed 's/x/x/;;s/x/x/'}
 sed: 1: s/x/x/;;s/x/x/: invalid command code ;
 @end example
 
-Input should not have unreasonably long lines, since some @command{sed}
-implementations have an input buffer limited to 4000 bytes.  Likewise,
+Some @command{sed} implementations have a buffer limited to 4000 bytes,
+and this limits the size of input lines, output lines, and internal
+buffers that can be processed portably.  Likewise,
 not all @command{sed} implementations can handle embedded @code{NUL} or
 a missing trailing newline.
 
-- 
1.7.6.5


From 0445b4ad121e6356f409833dec3678ae613e1d08 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 5 Jan 2012 12:32:12 -0800
Subject: [PATCH 2/2] doc: mention Bash 2.03 bug with backslash-newline

* doc/autoconf.texi (Invoking the Shell): New section.
(Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
Mention problem with Bash 2.03.
---
 ChangeLog |5 
 doc/autoconf.texi |   56 +---
 2 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 238c09f..69df405 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2012-01-05  Paul Eggert  egg...@cs.ucla.edu
 
+   doc: mention Bash 2.03 bug with backslash-newline
+   * doc/autoconf.texi (Invoking the Shell): New section.
+   (Backslash-Newline-Empty): Rename from Backslash-Newline-Newline.
+   Mention problem with Bash 2.03.
+
doc: clarify sed buffer limit
* doc/autoconf.texi (Limitations of Usual Tools):
That 4000-byte limit applies to output and internal buffers, too.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ea2419b..5c3feef 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -501,6 +501,7 @@ Dependencies Between Macros
 Portable Shell Programming
 
 * Shellology::  A zoology of shells
+* Invoking the Shell::  Invoking the shell as a command
 * Here-Documents::  Quirks and tricks
 * File Descriptors::FDs and redirections
 * Signal Handling:: Shells, signals, and headaches
@@ -520,7 +521,7 @@ Portable Make Programming
 * $ in Ordinary Make Rules::   $ in ordinary rules
 * Failure in Make Rules::   Failing portably in rules
 * Special Chars in Names::  Special Characters in Macro Names
-* Backslash-Newline-Newline::   Empty last lines in macro definitions
+* Backslash-Newline-Empty:: Empty lines after backslash-newline
 * Backslash-Newline Comments::  Spanning comments across line boundaries
 * Long Lines in Makefiles:: Line length limitations
 * Macros and Submakes:: @code{make macro=value} and submakes
@@ -15067,6 +15068,7 @@ subset described above, is fairly portable nowadays.  
Also please see
 
 @menu
 * Shellology::  A zoology of shells
+* Invoking the Shell::  Invoking the shell as a command
 * Here-Documents::  Quirks and tricks
 * File Descriptors::FDs and redirections
 * Signal Handling:: Shells, signals, and headaches
@@ -15205,6 +15207,28 @@ The default Mac OS X @command{sh} was originally Zsh; 
it was changed to
 Bash in Mac OS X 10.2.
 @end table
 
+@node Invoking the Shell
+@section Invoking the Shell
+@cindex invoking the shell
+@cindex shell invocation
+
+Bash 2.03 has a bug when invoked with the @option{-c} option: if the
+option-argument ends in backslash-newline, Bash incorrectly reports a
+syntax error.  The problem does not occur if a character follows the
+backslash:
+
+@example
+$ @kbd{$ bash -c 'echo foo \}
+ @kbd{'}
+bash: -c: line 2: syntax error: unexpected end of file
+$ @kbd{bash -c 'echo foo \}
+ @kbd{ '}
+foo
+@end example
+
+@noindent
+@xref{Backslash-Newline

Re: [PATCH] drop Win32 term

[Paul Eggert]

On 01/04/12 05:37, Stefano Lattarini wrote:
 Care to fix those too?

Here's a revised version of Bruno's patch that
attempts to address all the issues that you raised.

From ef5461d37207a965217e1b09c8ef257622f9d43c Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Wed, 4 Jan 2012 07:51:07 -0800
Subject: [PATCH] cosmetics: prefer the term native Windows over Win32

Microsoft has renamed the Win32 API to Windows API:
  http://msdn.microsoft.com/en-us/library/aa383723.aspx

Also, after some discussion on bug-gnulib, when talking about hosts and
platforms we believe it's better to talk about native Windows instead:
  https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg9.html
  https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00027.html
---
 doc/automake.texi |3 ++-
 lib/Automake/XFile.pm |2 +-
 lib/ar-lib|2 +-
 lib/compile   |4 ++--
 tests/compile2.test   |2 +-
 5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index a346233..fb584b6 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10242,7 +10242,8 @@ test.  For instance, @command{false} (from GNU 
coreutils) is never
 successful, even for @option{--help} or @option{--version}.  You can list
 such programs in the variable @code{AM_INSTALLCHECK_STD_OPTIONS_EXEMPT}.
 Programs (not scripts) listed in this variable should be suffixed by
-@samp{$(EXEEXT)} for the sake of Win32 or OS/2.  For instance, suppose we
+@samp{$(EXEEXT)} for the sake of native Windows or OS/2.
+For instance, suppose we
 build @file{false} as a program but @file{true.sh} as a script, and that
 neither of them support @option{--help} or @option{--version}:
 
diff --git a/lib/Automake/XFile.pm b/lib/Automake/XFile.pm
index 4ba84ce..68b1750 100644
--- a/lib/Automake/XFile.pm
+++ b/lib/Automake/XFile.pm
@@ -176,7 +176,7 @@ C\n on input files.
 
 =cut
 
-# Some Win32/perl installations fail to translate \r\n to \n on input
+# Some native Windows/perl installations fail to translate \r\n to \n on input
 # so we do that here.
 sub getline
 {
diff --git a/lib/ar-lib b/lib/ar-lib
index 4883fef..d90c636 100755
--- a/lib/ar-lib
+++ b/lib/ar-lib
@@ -42,7 +42,7 @@ file_conv=
 
 # func_file_conv build_file
 # Convert a $build file to $host form and store it in $file
-# Currently only supports Win32 hosts.
+# Currently only supports native Windows hosts.
 func_file_conv ()
 {
   file=$1
diff --git a/lib/compile b/lib/compile
index bac481c..de0e447 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand `-c -o'.
 
-scriptversion=2010-11-15.09; # UTC
+scriptversion=2012-01-04.15; # UTC
 
 # Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009, 2010 Free Software
 # Foundation, Inc.
@@ -40,7 +40,7 @@ file_conv=
 
 # func_file_conv build_file lazy
 # Convert a $build file to $host form and store it in $file
-# Currently only supports Win32 hosts. If the determined conversion
+# Currently only supports native Windows hosts. If the determined conversion
 # type is listed in (the comma separated) LAZY, no conversion will
 # take place.
 func_file_conv ()
diff --git a/tests/compile2.test b/tests/compile2.test
index c89be9f..1894d63 100755
--- a/tests/compile2.test
+++ b/tests/compile2.test
@@ -65,7 +65,7 @@ test -f $amtest_object
 # Absolute w32 paths should be accepted.
 # Do not actually run this test on anything that could be w32.
 if test -d 'C:\'; then
-  skip_ this test shouldn't run on a win32-like system
+  skip_ this test shouldn't run on a native Windows-like system
 fi
 case $PATH_SEPARATOR in
  ';'|':');;
-- 
1.7.6.4

bug#7893: HP-UX make causes autoconf timestamp issues

[Paul Eggert]

That issue is now documented in the INSTALL file, as well
as in the Autoconf manual.  Here's the relevant commit:

http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=2d082fa1ca25a16b60fb874e80f51ee79408e1f4

Re: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/26/11 13:35, Stefano Lattarini wrote:
 testing on non-Linux systems (*BSD and Solaris at least, hopefully also
 Cygwin or MinGW).

I tested it on Solaris 8 and that test worked fine.
I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'.

Some of the other tests failed, e.g., because I didn't have
Fortran installed, but I didn't investigate them; it hardly
seems worth the trouble for such an old system.

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/26/11 09:42, Stefano Lattarini wrote:
 And here is the follow-up tweaking for the test cases I had
 promised.  I will push in a couple of days if there is no objection.

Thanks, that looks good to me; please push it as soon as you like.

Re: bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/26/11 09:42, Stefano Lattarini wrote:
 And here is the follow-up tweaking for the test cases I had
 promised.  I will push in a couple of days if there is no objection.

Thanks, that looks good to me; please push it as soon as you like.

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/23/11 00:50, Stefano Lattarini wrote:
 could you apply the patch *not to maint nor to master*, but to a *new*
 branch (say `silent-fixes' or `silent-portability') based off of maint,
 and push that new branch to the public automake repo?

OK, done, as 'silent-fixes', with your recent nit-fixes applied.

Here's a URL for anyone else who wants to follow along:

http://git.savannah.gnu.org/cgit/automake.git/log/?h=silent-fixes

Re: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/23/11 00:50, Stefano Lattarini wrote:
 could you apply the patch *not to maint nor to master*, but to a *new*
 branch (say `silent-fixes' or `silent-portability') based off of maint,
 and push that new branch to the public automake repo?

OK, done, as 'silent-fixes', with your recent nit-fixes applied.

Here's a URL for anyone else who wants to follow along:

http://git.savannah.gnu.org/cgit/automake.git/log/?h=silent-fixes

bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/06/11 11:02, Stefano Lattarini wrote:
 If you are interested in accomodating this fringe situation, I will
 then accept a patch on the lines Paul has proposed (with a mandatory
 testcase, otherwise it would be far too easy to regress in such a
 almost-never-excercised corner case).

OK, a proposed patch is below.  It changes the silent-rules test case
to check the new behavior; hope that's what you're asking for.
Comments are welcome.

The patch below is just the human-edited parts.  A full patch
(including the autogenerated parts) is attached, as a compressed file.

automake: port silent-rules option to POSIX make
This fixes two problems reported for Automake (Bug#9928, Bug#10237)
and is in response to a bug report for building coreutils on
HP NonStop OS (Bug#10234).  The basic idea is that instead of
generating Makefile.in lines like AM_V_CC = $(am__v_CC_$(V)),
we generate AM_V_CC = $(am__v_CC_@am__V@).  We then AC_SUBST
$(V) for @am__V@ in the usual case where `make' supports
nested variables, and substitute 1 (or 0) otherwise.
Similarly for usages like $(am__v_CC_$(AM_DEFAULT_VERBOSITY)).
* NEWS: Document this.
* automake.in (define_verbose_var): When defining the variable,
use @am__V@ rather than $(V), and likewise for
@am__DEFAULT_VERBOSITY@ and $(AM_DEFAULT_VERBOSITY).
(handle_options): silent-rules no longer overrides
portability-recursive.
* doc/automake.texi (Invoking Automake): silent-rules no longer
overrides portability-recursive.
(Automake silent-rules Option): Explain new system.
* m4/silent.m4 (AM_SILENT_RULES): Check whether `make' supports
nested variables, and substitute am__V and am__DEFAULT_VERBOSITY
accordingly.
* tests/silent-nowarn.test: Check that silent-rules no longer
overrides portability-recursive.
diff --git a/NEWS b/NEWS
index da9af08..615f420 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+* Changes to automake:
+
+  - The `silent-rules' option now generates working makefiles even for
+the uncommon `make' implementations that do not support the
+nested-variables extension to POSIX 2008.  For such `make'
+implementations, whether a build is silent is determined at
+configure time, and cannot be overridden at make time with `make
+V=0' or `make V=1'.  Since the `silent-rules' option no longer
+requires nested variables, it no longer disables the
+nested-variables warning.
+
 New in 1.11a:

 * Changes to automake:
diff --git a/automake.in b/automake.in
index 0b6d014..d61af86 100644
--- a/automake.in
+++ b/automake.in
@@ -1141,9 +1141,8 @@ sub define_verbose_var ($$)
 my $silent_var = $pvar . '_0';
 if (option 'silent-rules')
   {
-   # Using `$V' instead of `$(V)' breaks IRIX make.
-   define_variable ($var, '$(' . $pvar . '_$(V))', INTERNAL);
-   define_variable ($pvar . '_', '$(' . $pvar . 
'_$(AM_DEFAULT_VERBOSITY))', INTERNAL);
+   define_variable ($var, '$(' . $pvar . '_@'.'am__V'.'@)', INTERNAL);
+   define_variable ($pvar . '_', '$(' . $pvar . 
'_@'.'am__DEFAULT_VERBOSITY'.'@)', INTERNAL);
Automake::Variable::define ($silent_var, VAR_AUTOMAKE, '', TRUE, $val,
'', INTERNAL, VAR_ASIS)
  if (! vardef ($silent_var, TRUE));
@@ -1236,10 +1235,6 @@ sub handle_options
   return 1 if process_option_list (@options);
 }

-  # Override portability-recursive warning.
-  switch_warning ('no-portability-recursive')
-if option 'silent-rules';
-
   if ($strictness == GNITS)
 {
   set_option ('readme-alpha', INTERNAL);
diff --git a/doc/automake.texi b/doc/automake.texi
index e937715..8214787 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -2702,8 +2702,6 @@ variables.
 The categories output by default are @samp{syntax} and
 @samp{unsupported}.  Additionally, @samp{gnu} and @samp{portability}
 are enabled in @option{--gnu} and @option{--gnits} strictness.
-On the other hand, the @option{silent-rules} options (@pxref{Options})
-turns off portability warnings about recursive variable expansions.

 @c Checked by extra-portability.test
 Turning off @samp{portability} will also turn off @samp{extra-portability},
@@ -10141,19 +10139,14 @@ Users who prefer to have silent rules enabled by 
default can edit their
 default to @samp{yes}.  This should still allow disabling silent rules
 at @command{configure} time and at @command{make} time.

-@c FIXME: there's really a need to specify this explicitly?
-For portability to different @command{make} implementations, package authors
-are advised to not set the variable @code{V} inside the @file{Makefile.am}
-file, to allow the user to override the value for subdirectories as well.
-
-The current implementation of this feature relies on a non-POSIX, but in
-practice rather widely supported @file{Makefile} construct of nested
-variable expansion @samp{$(@var{var1}$(V))}.  Do not use the
-@option{silent-rules} option if your package needs to build with
-@command{make} implementations that do not support it.  The

bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

If AM_SILENT_RULES is used, Automake generates Makefile.in
files with lines like this:

  AM_V_CC = $(am__v_CC_$(V))
  am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))

and these are copied into Makefile unchanged.  Unfortunately, as
the Automake documentation notes, these lines do not conform to
the POSIX rules for 'make', and as a result packages like
Coreutils that use AM_SILENT_RULES won't build on machines whose
'make' implementations conform to POSIX but disagree with GNU make
in this area.  This is a problem with the current release of
Coreutils, which doesn't build on HP's NonStop OS (see Bug#10234).

The simplest fix for Coreutils is to not use AM_SILENT_RULES but
that defeats the purpose of the Automake feature.  How about the
following idea instead?  Automake could put something like the
following into Makefile.in:

  AM_V_CC = $(am__v_CC_@AM_V@)
  am__v_CC_ = $(am__v_CC_@AM_DEFAULT_VERBOSITY@)

and then Automake can do something like this:

if make supports $(...$(...)); then
  AM_V='$(V)'
  AM_DEFAULT_VERBOSITY='$(AM_DEFAULT_VERBOSITY)'
else
  AM_V=1
  AM_DEFAULT_VERBOSITY=1
fi
AC_SUBST([AM_V])
AC_SUBST([AM_DEFAULT_VERBOSITY])

That way, Coreutils could continue to use AM_SILENT_RULES, and
these rules would work as usual on most hosts that use GNU
make-ish syntax in this area, but the rules wouldn't break on
hosts that support POSIX but not GNU make.

This idea should also fix Bug#9928 (in a different way from
what's proposed there), so I'll CC: its reporter.

bug#10237: bug#10234: Coreutils incompatibility with POSIX make

[Paul Eggert]

On 12/06/11 09:36, Jim Meyering wrote:
 I am very reluctant to
 sacrifice the above default solely to accommodate that system.

Yes, the make chatter is annoying, but on the other
hand being portable is pretty important too.  It's not just
NonStop; NextStep 'make' has a similar problem, and I wouldn't
be surprised if it crops up on other (admittedly minor) targets.

I have filed a bug report against this with Automake; see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10237
(warning: the GNU mailing list software has turned some
@s into  at s in that patch.)

Let's see if we can get it solved that way
-- it shouldn't be too hard, and it'd be much nicer.

bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/06/11 10:19, Stefano Lattarini wrote:
 which will also very likely be in the next POSIX standard, if I'm not
 mistaken)

Do you have a reference for that?  That would allay some of
my concerns in this area, moving forward.

 I'm extremely reluctant to add yet more complexity to automake

I don't see this change as adding much complexity.  It should be
pretty simple, and it shouldn't affect Automake much.  So I guess
the question is: how much complexity is too much?  I don't want
to bother to write and test a patch if it's going to be shot down
no matter how simple it is.

It is a bit off-putting to tell someone trying to install
coreutils well, you're going to have to install
all this other GNU stuff first.  (And suppose GNU make
starts depending on coreutils?...)  It's better to avoid these
dependencies if it's easy, which seems to be the case here.

bug#10237: AM_SILENT_RULES does not work with NonStop make

[Paul Eggert]

On 12/06/11 15:16, Daniel Richard G. wrote:
 (Paul: Does $({}) work on NonStop?)

I don't know, sorry.

I wanted a solution that worked
on any POSIX platform -- POSIX 2008 says that
$(aaa${bbb}) is just as unspecified as
$(aaa$(bbb)) is, and I wanted to play it safe.

Part of this is my experience with implementers who
code from the spec, so that their implementations'
quirks are not necessarily those of the historical
code.

bug#10210: [PATCH] lib/depcomp: spelling fix in usage message

[Paul Eggert]

Found while spell-checking Emacs.  Here's a proposed patch.
There are similar misspellings in
the ChangeLogs but that's less important.

depcomp: spelling fix
* lib/depcomp (-h): Fix misspelling in usage diagnostic.
diff --git a/lib/depcomp b/lib/depcomp
index 9825d56..b97ed64 100755
--- a/lib/depcomp
+++ b/lib/depcomp
@@ -1,7 +1,7 @@
 #! /bin/sh
 # depcomp - compile a program generating dependencies as side-effects

-scriptversion=2011-04-16.09; # UTC
+scriptversion=2011-12-04.01; # UTC

 # Copyright (C) 1999, 2000, 2003, 2004, 2005, 2006, 2007, 2009, 2010,
 # 2011 Free Software Foundation, Inc.
@@ -44,7 +44,7 @@ Environment variables:
   object  Object file output by `PROGRAMS ARGS'.
   DEPDIR  directory where to store dependencies.
   depfile Dependency file to output.
-  tmpdepfile  Temporary file to use when outputing dependencies.
+  tmpdepfile  Temporary file to use when outputting dependencies.
   libtool Whether libtool is used (yes/no).

 Report bugs to bug-automake@gnu.org.

bug#10083: [PATCH] * lib/install-sh: Spelling fix in comment.

[Paul Eggert]

(This patch was originally installed in Emacs; I'd like to
propagate it upstream.)

---
 ChangeLog  |4 
 lib/install-sh |4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c9dddb4..1f32cad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2011-11-19  Paul Eggert  egg...@cs.ucla.edu
+
+   * lib/install-sh: Spelling fix in comment.
+
 2011-11-10  Stefano Lattarini  stefano.lattar...@gmail.com
 
tests: avoid a spurious failure of 'ltinit.test' MinGW
diff --git a/lib/install-sh b/lib/install-sh
index a9244eb..64c4b3e 100755
--- a/lib/install-sh
+++ b/lib/install-sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile
 
-scriptversion=2011-01-19.21; # UTC
+scriptversion=2011-11-20.07; # UTC
 
 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -354,7 +354,7 @@ do
  if test -z $dir_arg || {
   # Check for POSIX incompatibilities with -m.
   # HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
-  # other-writeable bit of parent directory when it shouldn't.
+  # other-writable bit of parent directory when it shouldn't.
   # FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
   ls_ld_tmpdir=`ls -ld $tmpdir`
   case $ls_ld_tmpdir in
-- 
1.7.6.4

bug#10083: Acknowledgement ([PATCH] * lib/install-sh: Spelling fix in comment.)

[Paul Eggert]

I pushed this as trivial (thanks to Jim), and am closing it.

bug#8493: autoconf fails if env var U set

[Paul Eggert]

On 04/13/2011 11:02 AM, Tom Lane wrote:
 If the intended use is only for ansi2knr, I'd even argue that it
 should be off by default ... how many people care about ansi2knr
 anymore?

Nobody.  It would be fine to remove the ansi2knr stuff from Autoconf.

Re: Patch proposal: Add --clean options to unbootstrap a project.

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 +  xsystem (rm -rf '$cache')

This won't work well if $cache contains an apostrophe.

I realize this sort of problem is not new to the patch, but while
we're making changes in this area, why not fix it?  Either check for
and reject cache names containing apostrophe, or (better yet) support
the names.

Re: automatic update Makefile.am - Makefile.in - Makefile no longer working

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 I think this should be applied to HEAD and branch-1-10.
 Would you like me to do it?

Yes, please.  And thanks for your review; your points all look right
to me.

 So this is yet another reason to keep Autoconf version incompatibilities
 as few as possible.

Yes, quite right.

Re: automatic update Makefile.am - Makefile.in - Makefile no longer working

[Paul Eggert]

Bruno Haible [EMAIL PROTECTED] writes:

 Are we now supposed to edit Makefile.in by hand each time we modify
 Makefile.am?

I hope not.  How about the following (untested) Automake patch?

2007-06-20  Paul Eggert  [EMAIL PROTECTED]

* aclocal.in (write_aclocal): Warn about autoconf
incompatibilities instead of making them fatal.
Problem reported by Bruno Haible in
http://lists.gnu.org/archive/html/bug-automake/2007-06/msg00010.html.

Index: aclocal.in
===
RCS file: /cvs/automake/automake/aclocal.in,v
retrieving revision 1.140
diff -p -u -r1.140 aclocal.in
--- aclocal.in  14 Oct 2006 17:40:25 -  1.140
+++ aclocal.in  21 Jun 2007 05:32:18 -
@@ -783,9 +783,9 @@ sub write_aclocal ($@)
   # use it in the header below.  autom4te will output the name of
   # the file in the diagnostic anyway.
   $output = m4_if(m4_PACKAGE_VERSION, [$ac_version],,
-[m4_fatal([this file was generated for autoconf $ac_version.
-You have another version of autoconf.  If you want to use that,
-you should regenerate the build system entirely.], [63])])
+[m4_warning([this file was generated for autoconf $ac_version.
+You have another version of autoconf.  It may work, but it may not.
+If you have problems, you may need to regenerate the build system entirely.])])
 
 $output;
 }

Re: M4 syntax $11 vs. ${11}

[Paul Eggert]

Eric Blake [EMAIL PROTECTED] writes:

 +  /* This warning must not kill m4 -E, or it will break autoconf.  */
 +  if (text  strstr (text, ${))
 +M4ERROR ((0, 0, Warning: raw `${' in defn of %s will change semantics,
 +   name));

This warning will generate a lot of false positives, right?
Most of the time, a stray ${ in an M4 file won't be followed
by a series of digits and then a }.  So it will be treated
as itself (for backward compatibility).

I suggest having the warning complain only about ${X}, where X is a
string of one or more ASCII digits.  It shouldn't complain about
other usages of ${.  If you do it that way, you shouldn't need
to change either Autoconf or Automake.

Re: 1.10a instspc.test failure

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 2007-01-17  Ralf Wildenhues  [EMAIL PROTECTED]

   * doc/autoconf.texi (Setting Output Variables): Mention that
   all non-NUL characters are ok in substituted values.
   * lib/autoconf/status.m4 (_AC_SED_CMD_LIMIT): Fix comment typo.
   (_AC_OUTPUT_FILES_PREPARE): Test and use backslash escaping of
   carriage return for $AWK, needed for BSD awk.
   * tests/torture.at (Substitute and define special characters):
   Test all 8 bit non-NUL characters.
   Report against Automake by Patrick Welche.

That looks good to me, thanks.  (And beyond the call of duty.)

Please install.  I wouldn't bother with Mingw.

Re: 1.10a instspc.test failure

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

 -is called.  The value can contain newlines.
 +is called.  The value can contain all ASCII characters except for
 +the @code{NUL} character and carriage return; newline is ok to use.

If we can assume POSIX conformance with a reasonable C locale, the
value should be able to contain any non-NUL character.  There might be
a line length limit, but that's a different issue.

So I'd rather not document the problem with carriage return as a
feature of Autoconf.  It would be OK for now to document it as a bug,
though.  Something like this:

  In principle the value can contain any [EMAIL PROTECTED] character,
  including newline.  However, due to deficiencies in common Awk
  implementations, it is unwise to put carriage returns or
  [EMAIL PROTECTED] characters into the value.

Re: ``install -C'' / unnecessarily updating time stamps

[Paul Eggert]

Ralf Wildenhues [EMAIL PROTECTED] writes:

   * tests/defs.in (is_newest): Cope with multiple newer files.
   * NEWS: mention `install-sh -C'.

Thanks, please apply.

Re: ``install -C'' / unnecessarily updating time stamps

[Paul Eggert]

Benoit Sigoure [EMAIL PROTECTED] writes:

 http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html

I installed the following to Automake install-sh to implement
install-sh -C, which is the second part of that patch.

2006-12-25  Paul Eggert  [EMAIL PROTECTED]

* lib/install-sh (initialize_posix_glob): New var.
Use it instead of setting posix_glob inline.
(posix_glob): Use '?'/''/: instead of ''/yes/no, for convenience.
(cmpprog, CMPPROG): New vars, since we use cmp rather than the diff
of Akim's patch.
Use LC_ALL before invoking 'ls' when we depend on its output format.
Don't use awk; just use the shell's builtin features.
Clean up $dsttmp -C detects no installation is needed.
* tests/defs.in (is_newest): Renamed from is_younger; the new
name is more accurate.  All uses changed.
(old_timestamp): New var.
* tests/instsh2.test: Rewrite to avoid the need for sleeping.

2006-12-25  Akim Demaille  [EMAIL PROTECTED]

* lib/install-sh: Implement install-sh -C.
(This patch is the remaining part of the patch proposed in

http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00077.html.)
(usage): Document it.
(copy_on_change): New var.
* tests/defs.in (is_younger): New function.
* tests/instsh2.test: Check install-sh -C.

Index: lib/install-sh
===
RCS file: /cvs/automake/automake/lib/install-sh,v
retrieving revision 1.38
diff -u -p -r1.38 install-sh
--- lib/install-sh  25 Dec 2006 06:30:28 -  1.38
+++ lib/install-sh  26 Dec 2006 05:20:50 -
@@ -1,7 +1,7 @@
 #!/bin/sh
 # install - install a program, script, or datafile

-scriptversion=2006-12-24.16
+scriptversion=2006-12-25.00

 # This originates from X11R5 (mit/util/scripts/install.sh), which was
 # later released in X11R6 (xc/config/util/install.sh) with the
@@ -61,13 +61,24 @@ fi
 chgrpprog=${CHGRPPROG-chgrp}
 chmodprog=${CHMODPROG-chmod}
 chownprog=${CHOWNPROG-chown}
+cmpprog=${CMPPROG-cmp}
 cpprog=${CPPROG-cp}
 mkdirprog=${MKDIRPROG-mkdir}
 mvprog=${MVPROG-mv}
 rmprog=${RMPROG-rm}
 stripprog=${STRIPPROG-strip}

-posix_glob=
+posix_glob='?'
+initialize_posix_glob='
+  test $posix_glob != ? || {
+if (set -f) 2/dev/null; then
+  posix_glob=
+else
+  posix_glob=:
+fi
+  }
+'
+
 posix_mkdir=

 # Desired mode of installed file.
@@ -85,6 +96,7 @@ dst=
 dir_arg=
 dst_arg=

+copy_on_change=false
 no_target_directory=

 usage=\
@@ -102,6 +114,7 @@ Options:
  --version  display version info and exit.

   -c(ignored)
+  -Cinstall only if different (preserve the last data modification 
time)
   -dcreate directories instead of installing files.
   -g GROUP  $chgrpprog installed files to GROUP.
   -m MODE   $chmodprog installed files to MODE.
@@ -111,13 +124,16 @@ Options:
   -Treport an error if DSTFILE is a directory.

 Environment variables override the default commands:
-  CHGRPPROG CHMODPROG CHOWNPROG CPPROG MKDIRPROG MVPROG RMPROG STRIPPROG
+  CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
+  RMPROG STRIPPROG
 

 while test $# -ne 0; do
   case $1 in
 -c) ;;

+-C) copy_on_change=true;;
+
 -d) dir_arg=true;;

 -g) chgrpcmd=$chgrpprog $2
@@ -373,21 +389,14 @@ do
*)  prefix='';;
   esac

-  case $posix_glob in
-   '')
- if (set -f) 2/dev/null; then
-   posix_glob=true
- else
-   posix_glob=false
- fi;;
-  esac
+  eval $initialize_posix_glob

   oIFS=$IFS
   IFS=/
-  $posix_glob  set -f
+  $posix_glob set -f
   set fnord $dstdir
   shift
-  $posix_glob  set +f
+  $posix_glob set +f
   IFS=$oIFS

   prefixes=
@@ -454,32 +463,49 @@ do
 { test -z $stripcmd || $doit $stripcmd $dsttmp; } 
 { test -z $chmodcmd || $doit $chmodcmd $mode $dsttmp; } 

-# Now rename the file to the real destination.
-{ $doit $mvcmd -f $dsttmp $dst 2/dev/null || {
-  # The rename failed, perhaps because mv can't rename something else
-  # to itself, or perhaps because mv is so ancient that it does not
-  # support -f.
-
-  # Now remove or move aside any old file at destination location.
-  # We try this two ways since rm can't unlink itself on some
-  # systems and the destination file might be busy for other
-  # reasons.  In this case, the final cleanup might fail but the new
-  # file should still install successfully.
-  {
-test ! -f $dst ||
-$doit $rmcmd -f $dst 2/dev/null ||
-{ $doit $mvcmd -f $dst $rmtmp 2/dev/null 
-  { $doit $rmcmd -f $rmtmp 2/dev/null; :; }
-} ||
-{ echo $0: cannot unlink or rename $dst 2
-  (exit 1); exit 1

Re: ``install -C'' / unnecessarily updating time stamps

[Paul Eggert]

Thomas Schwinge [EMAIL PROTECTED] writes:

 This brings up the following question: if `-C' shall be used a) by
 default in Autoconf's `AC_PROG_INSTALL' if available or b) if requested
 by the programmer through setting some flag, and `install-sh' supports
 `-C', but the system's `install' executable doesn't (which will, as far
 as I can tell, be the case on most systems as after this quoted patch has
 been applied to `install-sh'), which of the two installation programs
 shall be chosen: the native `install' for speed or `install-sh' for
 feature completeness and to accommodate the programmer's request?

Right now, the native install.

The long-term goal will be to support -C everywhere, but right now the
only short-term goal is for install-sh to support -C.  One step at a time.

Once coreutils install supports -C, I think AC_PROG_INSTALL should
prefer -C, but that's a later patch.