1.16j: test release incoming

[Jim Meyering]

Preparing to make the next test release...
This failed:

  n=50; ( make bootstrap && make -j$n check keep_testdirs=yes && make 
maintainer-check && make -j$n distcheck && make -j$n distcheck 
AM_TESTSUITE_MAKE="make -j$n" && make -j$n 
check-no-trailing-backslash-in-recipes && make -j$n check-cc-no-c-o ) >& makerr 
&

With this output around the error:

  tardir=automake-1.16j && ${TAR-tar} chof - "$tardir" | XZ_OPT=${XZ_OPT--e} xz 
-c >automake-1.16j.tar.xz
  tardir=automake-1.16j && ${TAR-tar} chof - "$tardir" | eval GZIP= gzip --best 
-c >automake-1.16j.tar.gz
  make[2]: Leaving directory '/home/j/w/co/automake/automake-1.16j/_build/sub'
  if test -d "automake-1.16j"; then find "automake-1.16j" -type d ! -perm -700 
-exec chmod u+rwx {} ';' && rm -rf "automake-1.16j" || { sleep 5 && rm -rf 
"automake-1.16j"; }; else :;
  fi
  make[1]: Leaving directory '/home/j/w/co/automake/automake-1.16j/_build/sub'
  make[1]: Entering directory '/home/j/w/co/automake/automake-1.16j/_build/sub'
  rm -rf doc/automake.dvi doc/automake.pdf doc/automake.ps doc/automake.html \
doc/automake-history.dvi doc/automake-history.pdf \
doc/automake-history.ps doc/automake-history.html
  rm -f bin/automake bin/aclocal bin/aclocal-1.16 bin/automake-1.16 
doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1 doc/automake-1.16.1 
lib/Automake/Config.pm t/ax/test-defs.sh t/a
  x/shell-no-trail-bslash t/ax/cc-no-c-o runtest t/perf/test-suite.log 
announcement
  rm -f tests-in-makefile-list.tmp tests-on-filesystem-list.tmp 
diff-in-tests-lists.tmp
  find . -type d ! -perm -700 -exec chmod u+rwx {} ';'
  rm -rf "/home/j/w/co/automake/automake-1.16j/_build/sub/cover_db"
  rm -rf doc/automake.t2d doc/automake.t2p doc/automake-history.t2d \
   doc/automake-history.t2p
  find: ‘./doc/automake.t2d’: No such file or directory
  rm -f t/get-sysconf.log t/pm/Cond2.log t/pm/Cond3.log t/pm/Condition.log 
t/pm/Condition-t.log t/pm/DisjCon2.log t/pm/DisjCon3.log 
t/pm/DisjConditions.log t/pm/DisjConditions-t.log
  t/pm/General.log t/pm/Version.log t/pm/Version2.log t/pm/Version3.log 
t/pm/Wrap.log t/instspc.log t/aclocal.log t/aclocal-I-order-1.log 
t/aclocal-I-order-2.log t/aclocal-I-order-3
  .log t/aclocal-I-and-install.log t/aclocal-acdir.log ...

I fixed that with the first attached diff. Then ran that command again...
and hit this:

  make[2]: Leaving directory '/t/am-release'
  make[1]: Leaving directory '/t/am-release'
   GEN   sc_sanity_gnu_grep
   GEN   sc_perl_protos
  ./t/ax/test-defs.sh:# for this whole subsecond-mtime problem. With this set 
to "sleep 1",
  Do not use "sleep x" in the above tests. Use "$sleep" instead.
  make: *** [maintainer/syntax-checks.mk:443: sc_tests_plain_sleep] Error 1

So I adjusted via the second attached change.
Now, I think it will succeed.
After which I'll push them and then build/upload the 1.16j test release.

>From c8fcdede16b034260d779ff3f064b84d55064000 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Wed, 27 Dec 2023 06:52:50 -0800
Subject: [PATCH 1/2] maint: avoid a racy distcheck failure

* lib/am/distdir.am (am__remove_distdir): Use ";" not "&&" after
the chmod-running find, so that a failing find doesn't cause the
entire rule to fail.  This could happen when a directory like
doc/automake.t2d being processed by find is concurrently deleted
by another rule.
---
 lib/am/distdir.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 301239de1..0dd3a2e3f 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -24,7 +24,7 @@ top_distdir = $(distdir)
 am__remove_distdir = \
   if test -d "$(distdir)"; then \
 find "$(distdir)" -type d ! -perm -700 -exec chmod u+rwx {} ';' \
-  && rm -rf "$(distdir)" \
+  ; rm -rf "$(distdir)" \
 ## On MSYS (1.0.17) it is not possible to remove a directory that is in
 ## use; so, if the first rm fails, we sleep some seconds and retry, to
 ## give pending processes some time to exit and "release" the directory
-- 
2.41.0.376.gcba07a324d


>From b79e21c53b8e6899ad4616b422d1d1dd32d13d49 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Wed, 27 Dec 2023 07:48:17 -0800
Subject: [PATCH 2/2] maint: avoid a false-positive syntax-check failure

* maintainer/syntax-checks.mk (sc_tests_plain_sleep): This would match
the "sleep 1" in a comment.  So filter out shell-style comments before
matching.
---
 maintainer/syntax-checks.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/maintainer/syntax-checks.mk b/maintainer/syntax-checks.mk
index c56313781..40e30d955 100644
--- a/maintainer/syntax-checks.mk
+++ b/maintainer/syntax-checks.mk
@@ -440,7 +440,8 @@ sc_tests_ls_t:
 # Use 

[bug#59991] [PATCH v2 0/3] Port tests to modern C

[Jim Meyering]

On Thu, Dec 15, 2022 at 10:19 PM Frederic Berat  wrote:
> From: Frédéric Bérat 
> Hello,
>
> There is ongoing work from both GCC and Clang community to set the C99 
> standard
> as the default one.
> In this context, Fedora packages were rebuilt with some warnings turned as
> errors to simulate the change. This leads to failures in Automake, that are
> attempted to be fixed, mainly in this patchset.
>
> Fred.
>
> Changes from v1:
>   - [PATCH 2/2] has been split in 2, in order to properly detail changes
> related to depcomp.sh. The code is untouched.
>
> ---
> Frédéric Bérat (3):
>   tests: Fix 'type defaults' error in link_cond due to main not being
> properly declared
>   tests: Fix implicit function declaration errors
>   tests: Fix implicit function declaration in ax/depcomp.sh
>
>  t/ax/depcomp.sh  |  4 ++--
>  t/c-demo.sh  |  1 +
>  t/cond35.sh  |  2 ++
>  t/dist-vs-built-sources.sh   |  1 +
>  t/lex-clean.sh   |  1 +
>  t/lex-multiple.sh|  4 
>  t/lex-nodist.sh  |  2 ++
>  t/link_cond.sh   |  2 +-
>  t/ltcond2.sh |  2 ++
>  t/ltconv.sh  |  6 ++
>  t/subobj-clean-lt-pr10697.sh | 10 +-
>  t/subobj-clean-pr10697.sh| 10 +-
>  t/tags-pr12372.sh|  3 ++-
>  t/yacc-basic.sh  |  1 +
>  t/yacc-clean.sh  |  4 
>  t/yacc-nodist.sh |  2 ++
>  16 files changed, 49 insertions(+), 6 deletions(-)

Hi Frederic,
Thanks for the work.
However, neither in this mail, nor in your original did I find a
corresponding patch.
Would you please resend them?

I looked here, too: https://bugs.gnu.org/59991

[bug#60807] [PATCH v2] tests: reuse am_cv_filesystem_timestamp_resolution

[Jim Meyering]

On Sat, Jan 14, 2023 at 4:19 PM Mike Frysinger  wrote:
> Rather than assume such coarse delays, re-use existing logic for
> probing the current filesystem resolution.  This speeds up the
> testsuite significantly.  On my system, it speeds -j1 up quite a
> lot -- by ~30%.  While I didn't gather many samples to produce a
> statistically significant distribution, my runs seem to be fairly
> consistent with the values below with deviations of <1 minute.
>
> $ time make -j1
> BeforeAfter
> real  33m17.182s  real  23m33.557s
> user  12m12.145s  user  12m12.763s
> sys   1m52.308s   sys   1m52.853s
>
> $ time make -j32
> BeforeAfter
> real  1m35.874s   real  1m4.908s
> user  14m24.664s  user  15m58.663s
> sys   2m9.297ssys   2m27.393s
>
> * configure.ac: Set test delays to am_cv_filesystem_timestamp_resolution.
> * t/aclocal-no-force.sh: Use slower sleep if subsecond APIs are missing.
> * t/ax/test-defs.in: Split sleep settings into separate variables.
> ---
>  configure.ac  | 10 +-
>  t/aclocal-no-force.sh | 12 
>  t/ax/test-defs.in |  5 ++---
>  3 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index dcf2d95566a0..d3a67d5ffec9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -172,15 +172,7 @@ result=no
>  test "x$am_cv_prog_ln" = xln && result=yes
>  AC_MSG_RESULT([$result])
>
> -# The amount we should wait after modifying files depends on the platform.
> -# On Windows '95, '98 and ME, files modifications have 2-seconds
> -# granularity and can be up to 3 seconds in the future w.r.t. the
> -# system clock.  When it is important to ensure one file is older
> -# than another we wait at least 5 seconds between creations.
> -case $build in
> -  *-pc-msdosdjgpp) MODIFICATION_DELAY=5;;
> -  *)   MODIFICATION_DELAY=2;;
> -esac
> +MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution
>  AC_SUBST([MODIFICATION_DELAY])
>
>  ## --- ##
> diff --git a/t/aclocal-no-force.sh b/t/aclocal-no-force.sh
> index 3e0c04d12f18..2e139d75cf74 100644
> --- a/t/aclocal-no-force.sh
> +++ b/t/aclocal-no-force.sh
> @@ -19,6 +19,18 @@
>
>  . test-init.sh
>
> +# Automake relies on high resolution timestamps in perl.  If support isn't
> +# available (see lib/Automake/FileUtils.pm), then fallback to coarse sleeps.
> +# The creative quoting is to avoid spuriously triggering a failure in
> +# the maintainer checks.
> +case ${sleep_delay} in
> +0*)
> +  if ! $PERL -e 'use Time::HiRes' 2>/dev/null; then
> +sleep='sleep ''2'
> +  fi
> +  ;;

Thanks, Mike. Thanks for this.
Do you feel like adjusting this in light of Paul's
recent change to require a version of Perl new enough to
always provide Time::HiRes support?

https://git.savannah.gnu.org/cgit/automake.git/commit/?id=01bf65daf6f6627b56fbe78fc436fd877ccd3537

bug#60807: [PATCH 1/2] mtime: use Time::HiRes::stat when available for subsecond resolution

[Jim Meyering]

On Sun, Jan 15, 2023 at 12:27 AM Mike Frysinger  wrote:
> On 14 Jan 2023 21:27, Jacob Bachmeyer wrote:
> > Mike Frysinger wrote:
> > > --- a/lib/Automake/FileUtils.pm
> > > +++ b/lib/Automake/FileUtils.pm
> > > @@ -42,6 +42,11 @@ use Exporter;
> > >  use File::stat;
> > >  use IO::File;
> > >
> > > +# Perl's builtin stat does not provide sub-second resolution.  Use 
> > > Time::HiRes
> > > +# if it's available instead.  Hopefully one day perl will update.
> > > +# https://github.com/Perl/perl5/issues/17900
> > > +my $have_time_hires = eval { require Time::HiRes; };
> > > +
> > >  use Automake::Channels;
> > >  use Automake::ChannelDefs;
> > >
> > > @@ -115,10 +120,18 @@ sub mtime ($)
> > >return 0
> > >  if $file eq '-' || ! -f $file;
> > >
> > > -  my $stat = stat ($file)
> > > -or fatal "cannot stat $file: $!";
> > > -
> > > -  return $stat->mtime;
> > > +  if ($have_time_hires)
> > > +{
> > > +  my @stat = Time::HiRes::stat ($file)
> > > +   or fatal "cannot stat $file: $!";
> > > +  return $stat[9];
> > > +}
> > > +  else
> > > +{
> > > +  my $stat = stat ($file)
> > > +   or fatal "cannot stat $file: $!";
> > > +  return $stat->mtime;
> > > +}
> > >  }
> >
> > If you change that variable to a constant, you can eliminate the runtime
> > overhead entirely, since Perl optimizes if(1) and if(0) and folds
> > constants at compile time.
> >
> > Something like:
> >
> > use constant HAVE_Time_HiRes => eval { require Time::HiRes; };
> >
> > Then:
> >
> > if (HAVE_Time_HiRes)
> >...
> >
> > If you do this, Perl will inline the block actually used and elide the
> > branch at runtime.  This is generally useful for any test that can only
> > go one way in a specific run of the program.
>
> thanks, i'll integrate that idea.  i'm by no means a perl programmer.

Thanks, Mike.
It looks like this has been resolved slightly differently by a recent
change from Paul Eggert, so I'm closing this.

Re: make check(s) pre-release problems

[Jim Meyering]

On Thu, Oct 6, 2022 at 1:28 PM Karl Berry  wrote:
>
> No errors on RHEL7+autoconf2.71
>
> Puzzling. Can you easily try RHEL8 or one of its derivatives?
> It surprises me that that is the culprit, but it seems possible.
>
> I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am
> using the OS-provided coreutils. I think I'll try compiling that from
> source.

My problem, at least on F36 was that I'd been using a version of GNU
make I probably built from git around July 11, 2021(!) -- "-v" reports
4.3.90, which is not helpful - I would have preferred to know the
commit.
Once I installed the official 4.3.90, that made it so all of HACKING's
pre-release commands pass for me:
make bootstrap
make -j12 check keep_testdirs=yes
make maintainer-check
make -j12 distcheck# regular distcheck
make -j12 distcheck AM_TESTSUITE_MAKE="make -j$j"  # parallelize makes
make -j12 check-no-trailing-backslash-in-recipes
make -j12 check-cc-no-c-o

FTR, using autoconf (GNU Autoconf) 2.72a.57-8b5e2

fix: autoreconf fails due to .m4 files added but not installed

[Jim Meyering]

A few days ago I was preparing to release grep and wanted to make sure
it'd work with the latest automake and autoconf, so I built and installed
each from master. That exposed these errors when bootstrapping grep. I
think it was a prerequisite to have run grep's "make maintainer-clean":

  configure.ac:41: warning: _AM_PROG_RM_F is m4_require'd but not\
m4_defun'd
  configure.ac:41: warning: _AM_PROG_XARGS_N is m4_require'd but not\
m4_defun'd
  configure:5058: error: possibly undefined macro: _AM_PROG_RM_F
  configure:5059: error: possibly undefined macro: _AM_PROG_XARGS_N

I've just pushed the attached fix.
Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7
so this doesn't need a NEWS update.

Mike, can you add an automake test that would have caught this?

>From 208f103f2607eaed95aa0d227c5627b4363ffb7b Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 23 May 2022 23:20:37 -0700
Subject: [PATCH] fix: autoreconf fails due to .m4 files added but not
 installed

* m4/local.mk (dist_automake_ac_DATA): Add both rmf.m4 and xargsn.m4.
Building grep from "make maintainer-clean" state, failed like this:
  configure.ac:41: warning: _AM_PROG_RM_F is m4_require'd but not\
m4_defun'd
  configure.ac:41: warning: _AM_PROG_XARGS_N is m4_require'd but not\
m4_defun'd
  configure:5058: error: possibly undefined macro: _AM_PROG_RM_F
  configure:5059: error: possibly undefined macro: _AM_PROG_XARGS_N
---
 m4/local.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/m4/local.mk b/m4/local.mk
index 3bc333b7b..7ed018996 100644
--- a/m4/local.mk
+++ b/m4/local.mk
@@ -46,6 +46,7 @@ dist_automake_ac_DATA = \
   %D%/options.m4 \
   %D%/python.m4 \
   %D%/prog-cc-c-o.m4 \
+  %D%/rmf.m4 \
   %D%/runlog.m4 \
   %D%/sanity.m4 \
   %D%/silent.m4 \
@@ -53,7 +54,8 @@ dist_automake_ac_DATA = \
   %D%/substnot.m4 \
   %D%/tar.m4 \
   %D%/upc.m4 \
-  %D%/vala.m4
+  %D%/vala.m4 \
+  %D%/xargsn.m4

 dist_system_ac_DATA = %D%/acdir/README

-- 
2.35.1.677.gabf474a5dd

Re: How to speed up 'automake'

[Jim Meyering]

On Mon, May 23, 2022 at 1:48 PM Karl Berry  wrote:
>
> I was going to bisect but if it doesn't fail for me in the first place... 
> :(
>
> Thanks. Indeed, reconfiguring etc. got rid of those errors.
>
> Now a bunch (12) of the Python tests are failing for me, presumably
> because of previous Python changes not playing nicely with my older
> Python version (2.7.5 on CentOS 7). Sigh. Not looking forward to
> figuring that out.
>
> Anyway, that's surely independent of empty dependency files,
> so I pushed Jan's change. Thanks! --karl

Thanks, Karl.
FYI, with that, all tests passed for me on Fedora 35.

Re: How to speed up 'automake'

[Jim Meyering]

On Tue, May 3, 2022 at 2:57 PM Karl Berry  wrote:
>
> I see no reason why mv would be so crucial.
>
> Hmm, I guess you're right. Thanks for the analysis.
>
> The purpose of the stamp files is to avoid partial files being written
> (and screwing up future makes), but if the file is zero bytes, it seems
> that problem cannot happen.
>
> Jim, do you agree? I'll install the change if yes. --thanks, karl.

Oops. Read this after writing the longer reply.
Yes. Thanks!

Re: How to speed up 'automake'

[Jim Meyering]

On Tue, May 3, 2022 at 3:55 PM Nick Bowler  wrote:
>
> On 2022-05-02, Karl Berry  wrote:
> > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@
> > + @: >>$@
> >
> > 1) does it actually speed anything up?
>
> The answer seems to be a resounding "yes".  I tried one of my packages
> on an old slow PC, and changing this one line in Makefile.in cuts almost
> 5 seconds off of the depfiles generation step in config.status.
>
> (All .deps directories manually deleted between runs as otherwise the
> rule commands will not be executed).
>
>   Before (x5):
>   % time config.status Makefile depfiles
>   real  0m15.320s
>   real  0m15.210s
>   real  0m15.210s
>   real  0m15.210s
>   real  0m15.220s
>
>   After (x5):
>   % time config.status Makefile depfiles
>   real  0m10.650s
>   real  0m10.550s
>   real  0m10.550s
>   real  0m10.550s
>   real  0m10.650s
>
> That 5 seconds is a relatively small part of total configure runtime but
> it is noticeable.
>
> So if make implementations have no problem including empty files (I tried
> a few and all seem OK with it) then it seems like a win.
>
> > 2) without the mv I fear we are no longer noticing write failure
>
> I think it's OK.  All shells that I know of set a failure status when
> redirection fails, at least for simple commands like that.

FYI, in general, the $@-t dance is not really about error detection so
much as persistent-error avoidance. For most uses of this idiom, we
must be careful that we don't end up with the target ($@) containing
the results of an incomplete or corrupted write **AND** an up-to-date
timestamp (the "persistent" part), so we update atomically only after
successful result creation into $@-t. However, in this case, we don't
care about the contents of that file: just the timestamp, so
eliminating the intermediate $@-t is a fine move.

Re: Need better release validation documentation/strategy.

[Jim Meyering]

On Fri, Apr 8, 2022 at 6:30 AM Bob Friesenhahn
 wrote:
> Today I saw an announcement for a new version of gzip.  It provided
> lots of data for how to verify the downloaded tarballs.  I recently
> saw a very similar announcement for a new version of libtool. I am not
> sure where the template of this announcement text is coming from, and
> if anyone has validated that recipients will be able to make sense of
> it.
>
> The problem is that the advice in the announcements regarding use of
> 'gpg' just doesn't work (commands fail),

That was my mistake, and I fixed it last night. We updated the
generated and recommended gpg-key-fetching command to be a wget
command that fetches from savannah. I presumed that it would just
work, but that was not true. I fixed it by adding my gpg key in the
"public information" section of each project for which I'm already
listed as an authorized uploader.

[bug#53951] [PATCH] m4: speed up filesystem modification checks

[Jim Meyering]

On Sat, Feb 12, 2022 at 2:07 AM Mike Frysinger  wrote:
> The current code sleeps at least 1 second to make sure the generated
> files are strictly newer than the source files.  It does this for a
> few reasons: POSIX only guarantees that `sleep` accept integers, and
> filesystems have a history (c.f. Windows) of bad timestamp resolution.
>
> For the first part, we can easily probe sleep to see if it accepts a
> decimal number with a fractional part -- just run `sleep 0.001`.
>
> For the second part, we can create two files and then run sleep in a
> loop to see when one is considered newer than the other.
>
> For many projects, this 1 second delay is largely amortized by the
> rest of the configure script.  Autoconf lends itself to being both
> large & slow.  But in projects with many smallish configure scripts
> with many cached vars, the time to rerun is dominated by this single
> sleep call.  For example, building libgloss against a compiler with
> many (60+) multilib configurations, we see:
> [Using sleep 1]
> $ time ./config.status
> real2m28.164s
> user0m33.651s
> sys 0m9.083s
> [Using sleep 0.1]
> $ time ./config.status
> real0m39.569s
> user0m33.517s
> sys 0m8.969s
>
> And in case anyone wonders, going below 0.1s doesn't seem to make a
> statistically significant difference, at least in this configuration.
> It appears to be within "noise" limits.
> [Using sleep 0.001]
> $ time ./config.status
> real0m39.760s
> user0m33.342s
> sys 0m9.080s
>
> * m4/sanity.m4: Determine whether `sleep` accepts fractional seconds.
> Determine (roughly) the filesystem timestamp resolution.  Use this to
> sleep less when waiting for generated file timestamps to update.

Nice work. I looked through the patch and didn't see any issue.

Re: minor docs alteration

[Jim Meyering]

On Tue, Jan 18, 2022 at 10:01 AM Mike Frysinger  wrote:
> On 31 May 2018 22:44, Jefferson Carpenter wrote:
> > Subject: [PATCH] automake.texi: clarify relationship between configure and
> >  build dir
> >
> > I know you what this meant, but as a kid this would have confused me - the
> > word "in" seems to imply that the "configure" file is inside of the build 
> > dir,
> > as if it should be copied there or something.  The word "from" makes it more
> > clear that the intended action is to run "../configure" (or more generally
> > "$SOURCE_DIR/configure") from the build dir.
> >
> > --- a/doc/automake.texi
> > +++ b/doc/automake.texi
> > @@ -866,7 +866,7 @@ The source tree is rooted in the directory containing
> >  @file{configure}.  It contains all the sources files (those that are
> >  distributed), and may be arranged using several subdirectories.
> >
> > -The build tree is rooted in the directory in which @file{configure}
> > +The build tree is rooted in the directory from which @file{configure}
> >  was run, and is populated with all object files, programs, libraries,
> >  and other derived files built from the sources (and hence not
> >  distributed).  The build tree usually has the same subdirectory layout
>
> thanks for the patch.  it looks like Karl took inspiration from your 
> suggestion
> and applied a fix to use "rooted in the current directory at the time 
> configure"
> phrasing instead.  i don't see a response in the group about it, so this is 
> more
> of an FYI :).
> http://git.savannah.gnu.org/cgit/automake.git/commit/?h=8e05f006415d1811785ab5dab1ea4ae5a44c184e

Thanks for going through old patches.

In general, if one of the maintainers writes a diff and does not
attribute any other source, one can almost always assume they wrote
the diff independently. I.e., if Karl or I took inspiration from a bug
report, we would attribute it in the commit log. Giving credit where
due is important, so we try to be diligent about it. Unfortunately, I
have not read enough of the old submitted diffs.

Re: [PATCH] Use gender-neutral pronouns in HACKING and t/README

[Jim Meyering]

On Tue, Jan 18, 2022 at 10:03 AM Mike Frysinger  wrote:
> On 08 Apr 2018 16:07, Matthew Leeds wrote:
> > ---
> >  HACKING  | 4 ++--
> >  t/README | 2 +-
>
> thanks for the patch.  looks like Jim fixed HACKING:
> http://git.savannah.gnu.org/cgit/automake.git/commit/?h=7665b8e209888c73ee4dc05256f4f09a703a01e5
>
> but your change to t/README still applies cleanly.

Thanks. I've adjusted the commit log and pushed.

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

[Jim Meyering]

On Tue, Jan 18, 2022 at 10:29 AM Mike Frysinger  wrote:
> On 18 Jan 2022 09:48, Jim Meyering wrote:
...
> > But IMHO that's too much duplication/syntax.
> > How about this instead?
> >
> >   case $(echo "$files" | wc -l) in 4|6) ;; *) false;; esac
>
> looks reasonable for POSIX shell.  not a fan of the one-line, but that style
> seems to be SOP for test code, so i won't whine too loudly :p.
>
> i assume you'll take care of writing the actual patch at this point since it
> was your idea ? :)

Sure. How about this?

From: Jim Meyering 
Date: Tue, 18 Jan 2022 02:00:22 -0800
Subject: [PATCH] tests: fix py-compile-basedir.sh: missing "test"

Prompted by a patch from Thomas Deutschmann ,
via https://lists.gnu.org/r/automake-patches/2022-01/msg1.html:
commit v1.16.1-26-gb279a0d46 ("tests: in python tests, do not
require .pyo files (for python3)") was missing a `test` call.
Reported to Gentoo at https://bugs.gentoo.org/715040.
* t/py-compile-basedir.sh: Rather than just adding the missing
"test", rewrite using a case statement, to avoid some duplication.
---
 t/py-compile-basedir.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/py-compile-basedir.sh b/t/py-compile-basedir.sh
index 44b6b07c1..22e605f9d 100644
--- a/t/py-compile-basedir.sh
+++ b/t/py-compile-basedir.sh
@@ -43,7 +43,7 @@ for d in foo foo/bar "$(pwd)/foo" . .. ../foo ''; do
   py_installed "$d2/sub/$f.pyc"
   files=$(find "$d2" | grep '\.py[co]$')
   # with new-enough Python3, there are six files.
-  test $(echo "$files" | wc -l) -eq 4 || $(echo "$files" | wc -l) -eq 6
+  case $(echo "$files" | wc -l) in 4|6) ;; *) false;; esac
   case $d2 in
 .|..) rm -f $files;;
*) rm -rf "$d2";;
--

Re: [PATCH] tests: fix py-compile-basedir.sh: add missing test call

[Jim Meyering]

On Tue, Jan 18, 2022 at 7:46 AM Mike Frysinger  wrote:
> From: Thomas Deutschmann 
>
> Commit b279a0d46dfeca1ca40057c3c910ab1657d60be5 ("tests: in python
> tests, do not require .pyo files (for python3)") had a slight logic
> error in that it missed a `test` call.
>
> Reported to Gentoo at https://bugs.gentoo.org/715040.
>
> * t/py-compile-basedir.sh: Add test command.
> ---
>  t/py-compile-basedir.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/py-compile-basedir.sh b/t/py-compile-basedir.sh
> index 44b6b07c1962..979f65710c0b 100644
> --- a/t/py-compile-basedir.sh
> +++ b/t/py-compile-basedir.sh
> @@ -43,7 +43,7 @@ for d in foo foo/bar "$(pwd)/foo" . .. ../foo ''; do
>py_installed "$d2/sub/$f.pyc"
>files=$(find "$d2" | grep '\.py[co]$')
># with new-enough Python3, there are six files.
> -  test $(echo "$files" | wc -l) -eq 4 || $(echo "$files" | wc -l) -eq 6
> +  test $(echo "$files" | wc -l) -eq 4 || test $(echo "$files" | wc -l) -eq 6

Thanks. Good catch.
If we were to use that, it's a little better to double-quote each
$(...) result, in case somehow the result is not just precisely one
token:

  test "$(echo "$files" | wc -l)" -eq 4 || test "$(echo "$files" | wc -l)" -eq 6

But IMHO that's too much duplication/syntax.
How about this instead?

  case $(echo "$files" | wc -l) in 4|6) ;; *) false;; esac

Re: multiple online manual versions

[Jim Meyering]

On Tue, Jan 18, 2022 at 8:14 AM Mike Frysinger  wrote:
> currently the automake website only hosts one manual version -- the latest.
> when working with older code bases, especially when trying to update them
> to newer versions, it can be helpful to have the older manual available to
> quickly refer to.  can we do this for automake ?  i'm thinking of just the
> major series (1.11, 1.12, etc...), not the patchlevel (1.16.1, 1.16.2).
>
> this is pretty common with other projects that have major releases and are
> heavily developer oriented.  for example:
> * autoconf
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-/
> * gcc
> https://gcc.gnu.org/onlinedocs/
> * binutils
> https://sourceware.org/binutils/docs-/
>
> the autoconf style should be pretty easy to replicate since it's using the
> same infrastructure as automake:
> https://web.cvs.savannah.gnu.org/viewvc/autoconf/autoconf/manual/

Makes sense.

FYI, updated copyrights

[Jim Meyering]

FYI, I've just updated copyright messages for the new year:
https://git.savannah.gnu.org/cgit/automake.git/commit/?id=6c8ff6a8f3c80f86e703a3fc2a0ffb81e87f0957

bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems

[Jim Meyering]

On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger  wrote:
> This fixes https://debbugs.gnu.org/21336.  On macOS 10.10, there seems

Note that I still see kcc on 12.0.1

> to be a kerberos tool installed as "kcc" which breaks the check.
>
> Also resync with latest autoconf which searches for clang++ too.
>
> * configure.ac: Skip KCC check on case-insensitive filesystems.  Add
> clang++ to the C++ search list.

Modulo that log nit, this commit looks fine. Thanks!

Re: [PATCH] configure: handle KCC on case-insensitive filesystems

[Jim Meyering]

On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger  wrote:
> This fixes https://debbugs.gnu.org/21336.  On macOS 10.10, there seems

Note that I still see kcc on 12.0.1

> to be a kerberos tool installed as "kcc" which breaks the check.
>
> Also resync with latest autoconf which searches for clang++ too.
>
> * configure.ac: Skip KCC check on case-insensitive filesystems.  Add
> clang++ to the C++ search list.

Modulo that log nit, this commit looks fine. Thanks!

Re: [PATCH] m4: replace AC_DIAGNOSE with m4_warn

[Jim Meyering]

On Sat, Dec 11, 2021 at 10:07 PM Mike Frysinger  wrote:
> AC_DIAGNOSE was marked obsolete with autoconf-2.62 in 2008.
>
> * m4/obsolete.m4: Change AC_DIAGNOSE to m4_warn.
> ---
>  m4/obsolete.m4 | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/m4/obsolete.m4 b/m4/obsolete.m4
> index 79f3b234bfc5..bf3b68271673 100644
> --- a/m4/obsolete.m4

Looks fine. Thanks!

Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used

[Jim Meyering]

On Sat, Dec 11, 2021 at 10:09 PM Mike Frysinger  wrote:
> To help ease people into enabling silent rules by default, warn if
> a package doesn't make an explicit selection.
> ---
>  NEWS | 10 ++
>  m4/silent.m4 |  6 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index fb05ee219708..282eb9277a3d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -3,6 +3,16 @@ please see NEWS-2.0 and start following the advice there now.
>
>  
>
> +New in 1.17:
> +
> +* Future changes
> +
> +  - In preparation for silent rules being enabled by default, issue warnings
> +when a default has not been selected.  This is shown to developers (who
> +run automake for their package) and for users (who run ./configure).

This seems sensible for the interim.
Do all of the self tests pass as-is, or do they all need to be
adjusted to suppress the new diagnostic?

Re: [RFC/PATCH] m4: enable silent build rules by default

[Jim Meyering]

On Sun, Dec 12, 2021 at 7:14 AM Zack Weinberg  wrote:
>
> On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote:
> > On 07 Dec 2021 21:58, Zack Weinberg wrote:
> >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote:
> >> > This has been available since automake 1.11 released over a decade
> >> > ago.  Let's flip the default to enable silent builds by default.
> >>
> >> Please don't *ever* make this change.  It is absolutely essential that the 
> >> default build output be verbose, else anyone who's stuck trying to debug a 
> >> build on a CI server that they have no direct access to is in a world of 
> >> hurt.
> >
> > people can trivially add --disable-silent-rules to their configure 
> > invocations.
> > i really don't think this is as onerous as you make it out to be.
>
> I can tell you've never had this experience, or you wouldn't say that.  And 
> probably you wouldn't be proposing this patch in the first place :-P
>
> There's some piece of software.  You don't know how its build system works, 
> and the process of configuring and building it is hidden behind at least one 
> layer of packaging automation.  It's got a bug in its build, but only on some 
> architecture you do not have shell access to, only some CI system that you do 
> not administer and whose only interface is "upload software, get back logs 
> minutes to hours later."  It builds Just Fine on your computer.
>
> The logs you got back from your first attempt to build it are useless because 
> the equivalent of --enable-silent-rules is on by default.
>
> You spend anywhere between five minutes and an hour figuring out which build 
> system the software uses, what its equivalent of --disable-silent-rules is, 
> and where to poke that into the packaging automation.  You throw another 
> build at the CI.  Half an hour later you get back logs that are *still* 
> useless because you misunderstood where the poke goes.
>
> You tinker with it on your computer and get the poke into the right place and 
> get back logs that are not useless.  You throw another build at the CI.  Half 
> an hour later you get back logs that are *still* useless because the CI uses 
> a slightly different build process (think pbuilder vs sbuild) and that means 
> the poke is still not in the right place.
>
> This cycle can go on for DAYS if you're sufficiently unlucky.
>
> Yes, an awful lot of this is the fault of the packaging automation and the CI 
> in question.  But Automake can't do shit about that.  But what Automake *can* 
> do is avoid making the situation even worse, by ... sticking to what it 
> already does: verbose builds by default.
>
> -
>
> I'd like to generalize the above point a little.  I saw someone (possibly 
> you) advocating for --enable-silent-rules by default because it makes it less 
> likely for actual warnings and errors to get lost amid a flood of chatter.  
> This is absolutely true.  I use --enable-silent-rules all the time on the 
> software that I work on frequently, because in *that* situation the chatter 
> *is* irrelevant -- I already have the build environment set up correctly, I'm 
> not going to need to figure out why the C compiler can't find  
> or anything like that.  And even with compilation-mode doing the actual work 
> of scanning for warnings, the terse log *is* easier on my poor tired brain.
>
> --enable-silent-rules is good for day-to-day maintenance.  
> --disable-silent-rules, on the other hand, is what people want when they have 
> no prior familiarity with some software, and they're just trying to fix one 
> bug, because in that situation they may *not* have things set up right and 
> the build system hiding details of what it's actually doing is more likely to 
> be aggravating than not.
>
> I'm arguing that the out-of-the-box, default behavior of Automake-driven 
> builds should optimize for the experience of people who are just trying to 
> fix one bug, *not* for the experience of day-to-day maintainers.  That might 
> sound backward but think about it.  Day-to-day maintainers have the time and 
> the incentive to set up customizations.  They have plenty of other reasons to 
> learn the ins and outs of the configuration process.  It's *easy* to get in 
> the habit of typing `./configure --enable-silent-rules` instead of just 
> `./configure` once you know that that does a thing you like.  The 
> out-of-the-box experience does not *need* to be tuned for regular 
> maintainers' convenience.  Rather, it should be tuned for the convenience of 
> people who have never tried to build the software before and do *not* have 
> the time or patience to mess with the defaults.

Hi Zack, Mike and Karl,

I argue that we must optimize for the vastly-more-numerous cohort:
consumers who are *NOT* in the unusual position of debugging some
arcane build failure whose origin is masked by using
AM_SILENT_RULES([yes]).

I've specified AM_SILENT_RULES([yes]) in any package I've ever tended,
and don't recall having or hearing 

Re: [platform-testers] automake-1.16g snapshot

[Jim Meyering]

On Mon, Sep 20, 2021 at 12:03 AM Dagobert Michelsen  wrote:
> Hi Jim,
>
> Am 20.09.2021 um 04:37 schrieb Jim Meyering :
> > We're preparing for a new release.
> > See NEWS below. Please give it a spin and report any success or failure.
> >
> > Thanks to Karl for doing so much of the work.
> >
> > There have been 11 commits by 6 people in the 8 weeks since 1.16.4.
> > See the NEWS below for a brief summary.
>
> I have an early build failure on help2man on Solaris 10 x86:
>
> gmake: Entering directory 
> '/home/dam/mgar/pkg/automake/trunk/work/solaris10-i386/build-isa-pentium_pro-version-1.16/automake-1.16'
>   GEN  bin/automake
>   GEN  bin/aclocal
>   GEN  bin/aclocal-1.16
>   GEN  bin/automake-1.16
>   GEN  t/ax/shell-no-trail-bslash
>   GEN  t/ax/cc-no-c-o
>   GEN  runtest
>   GEN  doc/aclocal.1
>   GEN  doc/automake.1
>   GEN  lib/Automake/Config.pm
>   GEN  doc/aclocal-1.16.1
>   GEN  doc/automake-1.16.1
> help2man: can't get `--help' info from automake-1.16
> Try `--no-discard-stderr' if option outputs to stderr
> gmake: *** [Makefile:3694: doc/automake-1.16.1] Error 255

Thanks for the speedy feedback!
Would you please see if reverting to the version of doc/help2man from
1.16.4 makes it work?

Also, building with V=1 will cause "make" to show more about commands
it is running. That may help, too.

automake-1.16g snapshot

[Jim Meyering]

We're preparing for a new release.
See NEWS below. Please give it a spin and report any success or failure.

Thanks to Karl for doing so much of the work.

There have been 11 commits by 6 people in the 8 weeks since 1.16.4.
See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Akim Demaille (1)
  Dimitri Papadopoulos (1)
  Jan Engelhardt (1)
  Jim Meyering (2)
  Karl Berry (5)
  Nick Bowler (1)

Jim [on behalf of the automake maintainers]

==
Here is the GNU automake home page:
http://gnu.org/s/automake/

Here are the compressed sources (.sig files are alongside):
  https://meyering.net/automake/automake-1.16g.tar.xz
  https://meyering.net/automake/automake-1.16g.tar.gz

Here are the SHA1 and SHA256 checksums:
0f100809419ecd93ef55fe4db348cf39e21ef3f8  automake-1.16g.tar.gz
64e23e07f1fd3951f80d1090304b328ab134a6a0  automake-1.16g.tar.xz
JstjNQG2jzC1Ci4riJVYwNt3i+FCvdb17hMR4hkZe+o  automake-1.16g.tar.gz
Wow6Qnn2fPmTMVBftfbptuM1PrLfYuB0fH9NkYbvHpA  automake-1.16g.tar.xz

Each SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

==
NEWS

* Bugs fixed

  - PYTHON_PREFIX and PYTHON_EXEC_PREFIX are now set according to
Python's sys.* values only if the new configure option
--with-python-sys-prefix is specified. Otherwise, GNU default values
are used, as in the past. (The change in 1.16.3 was too incompatible.)

  - consistently depend on install-libLTLIBRARIES.

* Distribution

  - use const for yyerror declaration in bison/yacc tests.


signature.asc
Description: PGP signature

Re: automake-1.16d snapshot

[Jim Meyering]

On Sun, Jul 18, 2021 at 8:06 PM Jim Meyering  wrote:
> We're preparing for a new release, so here's the latest.
> Please give it a spin and report any success or failure.
> I'd like to release 1.16.4 within a week or so.
>
> Thanks to Karl yet again for doing so much of the work.
>
> There have been 41 commits by 11 people in the 35 weeks since 1.16.3.
> See the NEWS below for a brief summary.
>
> Thanks to everyone who has contributed!
> The following people contributed changes to this release:
>
>   Allison Karlitskaya (2)
>   Dirk Mueller (1)
>   Jacob Bachmeyer (1)
>   Jim Meyering (7)
>   Joshua Root (1)
>   Karl Berry (25)
>   Mike Frysinger (1)
>   Nick Gasson (1)
>   Reuben Thomas (2)
>   Zack Weinberg (1)
>
> Jim [on behalf of the automake maintainers]
> ==
>
> Here is the GNU automake home page:
> http://gnu.org/s/automake/
>
> Here are the compressed sources:
>   https://meyering.net/automake/automake-1.16d.tar.xz
>   https://meyering.net/automake/automake-1.16d.tar.gz
>
> Their GPG signature .sig files are alongside.
>
> ==
> NEWS

Oops. I copied the news for 1.6.3 into this snapshot announcement.
Here's the news for the upcoming 1.6.4:

* New features added

  - The PYTHON_PREFIX and PYTHON_EXEC_PREFIX variables are now set from
Python's sys.prefix and sys.exec_prefix; use the new configure options
--with-python_prefix and --with-python_exec_prefix to specify explicitly.

  - Common top-level files can be provided as .md; the non-md version is
used if both are present:
  AUTHORS ChangeLog INSTALL NEWS README README-alpha THANKS

  - CTAGS, ETAGS, SCOPE variables can be set via configure.

  - Silent make output for custom link commands.

  - New option "no-dist-built-sources" skips generating $(BUILT_SOURCES)
before building the tarball as part of "make dist", that is,
omits the dependency of $(distdir): $(BUILT_SOURCES).

* Bugs fixed

  - automake output more reproducible.

  - test-driver less likely to clash with tests writing to the same file.

  - DejaGnu tests always use the directory name, testsuite/, for
compatibility with the newer dejagnu-1.6.3 and with prior versions.

* Distribution

  - config.sub and config.guess updates include restoration of `...`
for maximum portability.

automake-1.16d snapshot

[Jim Meyering]

We're preparing for a new release, so here's the latest.
Please give it a spin and report any success or failure.
I'd like to release 1.16.4 within a week or so.

Thanks to Karl yet again for doing so much of the work.

There have been 41 commits by 11 people in the 35 weeks since 1.16.3.
See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Allison Karlitskaya (2)
  Dirk Mueller (1)
  Jacob Bachmeyer (1)
  Jim Meyering (7)
  Joshua Root (1)
  Karl Berry (25)
  Mike Frysinger (1)
  Nick Gasson (1)
  Reuben Thomas (2)
  Zack Weinberg (1)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

Here are the compressed sources:
  https://meyering.net/automake/automake-1.16d.tar.xz
  https://meyering.net/automake/automake-1.16d.tar.gz

Their GPG signature .sig files are alongside.

==
NEWS

* New features added

  - In the testsuite summary, the "for $(PACKAGE_STRING)" suffix
can be overridden with the AM_TESTSUITE_SUMMARY_HEADER variable.

* Bugs fixed

  - Python version number 3.10 no longer considered to be 3.1.

  - Broken links in manual fixed or removed, and new script
contrib/checklinkx (a small modification of W3C checklink) added,
with accompany target checklinkx to recheck urls.

  - install-exec target depends on $(BUILT_SOURCES).

  - valac argument matching more precise, to avoid garbage in DIST_COMMON.

  - Support for Vala in VPATH builds fixed so that both freshly-generated and
distributed C files work, and operation is more reliable with or without
an installed valac.

  - Dejagnu doesn't break on directories containing spaces.

* Distribution

  - new variable AM_DISTCHECK_DVI_TARGET, to allow overriding the
"make dvi" that is done as part of distcheck.

* Miscellaneous changes

  - install-sh tweaks:
. new option -p to preserve mtime, i.e., invoke cp -p.
. new option -S SUFFIX to attempt backup files using SUFFIX.
. no longer unconditionally uses -f when rm is overridden by RMPROG.
. does not chown existing directories.

  - Removed function up_to_date_p in lib/Automake/FileUtils.pm.
We believe this function is completely unused.

  - Support for in-tree Vala libraries improved.


signature.asc
Description: PGP signature

Re: [PATCH v1] Fix misuse of DejaGnu in Automake testsuite

[Jim Meyering]

On Tue, Jul 13, 2021 at 9:39 PM Jacob Bachmeyer  wrote:
> This is a revised patch that changes the DejaGnu tests in the Automake
> testsuite to properly use a testsuite/ directory.  A previous "v0" of
> this patch was sent to the general Automake list as an illustration of
> the problem, but that version of the patch broke compatibility with all
> older releases of DejaGnu.  This version instead uses recursive make to
> run DejaGnu in the testsuite/ directory in each case.  This works with
> older versions of DejaGnu and this usage of DejaGnu will continue to be
> supported for the foreseeable future.
>
> On a side note, DejaGnu can now be run from its source tree or a Git
> working tree.  While the Automake testsuite does not seem to provide a
> way to set RUNTEST to point to an alternate runtest, "
> PATH=/where/you/put/dejagnu-1.6.3:$PATH make check " will use an
> unpacked version of the 1.6.3 release even if the system has an older
> version installed.  Older versions of DejaGnu did not support this reliably.

I confirmed that all tests pass for me on Fedora 34,
both with dejagnu-1.6.1 and with 1.6.3.
I've pushed that with a ChangeLog and NEWS added by Karl.
Thanks to both of you!

Re: Automake testsuite misuses DejaGnu

[Jim Meyering]

On Sun, Jul 11, 2021 at 9:03 PM Jacob Bachmeyer  wrote:
> I was planning to find a solution with a complete patch before
> mentioning this, but since a release is imminent I will just state the
> problem:  several tests in the Automake testsuite misuse DejaGnu and
> fail with the 1.6.3 DejaGnu release as a result.
>
> DejaGnu has always required a DejaGnu testsuite to be rooted at a
> "testsuite" directory and this has long been documented in the manual.
> However, prior to 1.6.3, DejaGnu did not actually depend on this
> requirement being met.  Changes during the development process to
> properly support non-recursive Automake makefiles required relying on
> this requirement to resolve the ambiguity between recursive and
> non-recursive usage.  Several tests in the Automake testsuite do not
> meet this requirement and fail if run with DejaGnu 1.6.3.
>
> The simple change of updating the tests to use a testsuite/ directory
> causes the tests to fail with older versions of DejaGnu, due to lack of
> support for non-recursive "make check" in those versions.  I have not
> yet tried a patch that also switches the tests to use recursive make,
> but I believe that is probably the only way for the tests to pass with
> old and new DejaGnu.
>
> Note that, according to the original author, Rob Savoye, DejaGnu has
> always been intended to require that testsuites be rooted at a
> "testsuite" directory and the behavior that Automake's test cases rely
> on was never supported.
>
> The affected tests are:  check12, dejagnu3, dejagnu4, dejagnu5,
> dejagnu6, dejagnu7, dejagnu-absolute-builddir, dejagnu-relative-srcdir,
> dejgnu-siteexp-extend, dejagnu-siteexp-useredit.
>
> Note that these tests do not all fail with the 1.6.3 release, but will
> all fail with some future release when the undocumented support for a
> testsuite not rooted at "testsuite" will eventually be removed.

Thank you for the analysis and heads-up.
I see that Fedora 34 currently has only dejagnu-1.6.1.
If this is something you can help with now, I can certainly wait a few days.

Even a sample fix for one of the currently-failing tests would be helpful.

snapshot imminent

[Jim Meyering]

Karl and I have just pushed a few changes (thanks, Karl and Allison!).
With those, I think we're ready for a release. I will make the usual
pre-release snapshot, probably tomorrow.

Re: [PATCH] dist: add new "pure-dist" automake option

[Jim Meyering]

On Mon, Jul 5, 2021 at 4:16 PM Jim Meyering  wrote:
> In incidentally-related news, I found that make check now hangs on
> tests-environment-fd-redirect on Fedora 34, so I'm investigating that.

FYI, I'm currently working around this by disabling the ksh-testing
part of that test:


fedora-ksh-hang-workaround.diff
Description: Binary data

Re: [PATCH] dist: add new "pure-dist" automake option

[Jim Meyering]

On Sun, Jul 4, 2021 at 2:19 PM Karl Berry  wrote:
>
>  - I used the word "pure" in the sense of a pure function,
>
> Yes, I realized.
>
> My thought was that, suppose some other similar change is needed in the
> future that changes what gets automatically distributed, or
> prerequisites, or whatever. However, we would not want to change the
> effect of "pure-dist", because of compatibility, even if theoretically
> this hypothetical change was also about "purity". Then the name would
> become more confusing than helpful.
>
> Therefore it seems better to me to describe what the option actually
> does (dist-no-built-sources) than to come up with a general name,
> even though it is (granted) prettier.
>
> static-dist isn't any different in that regard. I like pure-dist better
> than static-dist, of the two.
>
> I hear you about long option names, but ... I don't see a perfect answer
> here.
>
> By the way, looking at the current list of AUTOMAKE_OPTIONS, I think the
> name should definitely start with "dist-", whatever else.
>
> - My actual preference would be to have this be the default option.
> Might we have a path some day to a place where this is true,
> possibly after a transition period?
>
> Well, the decision is Jim's, as the primary maintainer. IMHO, retaining
> compatibility is more important than relatively minor behavior
> improvements when it comes to behavior of long-established programs like
> Automake. If the BUILT_SOURCES dependency had only started a year or two
> ago, maybe, but it's a lot older than that.
>
> Changing the default, at behavior any time, will inevitably induce
> significant hassle for maintainers of packages which depend, possibly
> unknowingly, on the current behavior. Having been that maintainer (on
> the receiving end) more times than I count for such gratuitous behavior
> "improvements", I prefer not to inflict it myself.
>
>  - I made a mistake: I added the tests, but I forgot to add them to the
> list of tests.
>
> I'll add it, no problem there. Thanks for the heads-up. -k

Thanks to both of you.
Let's go with dist-no-built-sources for the reasons Karl gave.
Once the patch is fixed to reference the new tests from
t/list-of-tests.mk, I saw only two other nits:
- the copyright date in a new file should include only the current year
- the test description should be updated (from copied file) to refer
to the new test, e.g.,
  # Ensure "dist-no-built-sources" option works as advertised.

Switching names means references to "impure" are no longer
appropriate, of course.

In incidentally-related news, I found that make check now hangs on
tests-environment-fd-redirect on Fedora 34, so I'm investigating that.

Re: Add support for README.md as optional alternative to README

[Jim Meyering]

On Mon, May 31, 2021 at 4:53 PM Karl Berry  wrote:
> Markdown is a great invention and I believe time has come for GNU packages
> to support README.md files as optional alternatives to plain READMEs.
>
> Seems fine to me. (Jim?) Thanks. -k

The patch is fine. Thanks indeed.

automake-1.16.3 released [stable]

[Jim Meyering]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is to announce automake-1.16.3, a stable release.

There have been 62 commits by 15 people in the 35 weeks since 1.16.2.
Special thanks to Karl Berry and Zack Weinberg for doing so much of the work.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Akim Demaille (1)
  Colomban Wendling (1)
  Felix Yan (1)
  Issam E. Maghni (1)
  Jim Meyering (12)
  Karl Berry (23)
  Miro Hron\v{c}ok (1)
  Paul Eggert (4)
  Reuben Thomas (3)
  Robert Menteer (1)
  Robert Wanamaker (1)
  Samuel Tardieu (1)
  Samy Mahmoudi (1)
  Vincent Lefevre (1)
  Zack Weinberg (10)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=automake.git;a=shortlog;h=v1.16.3
or run this command from a git-cloned automake directory:
  git shortlog v1.16.2..v1.16.3

Here are the compressed sources:
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.xz (1.6MB)
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.gz (2.3MB)

Here are the GPG detached signatures[*]:
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.xz.sig
  https://ftp.gnu.org/gnu/automake/automake-1.16.3.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify automake-1.16.3.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 7FD9FCCB000B

and rerun the 'gpg --verify' command.

Please report bugs and problems to ,
and send general comments and feedback to .

==
NEWS

* New features added

  - In the testsuite summary, the "for $(PACKAGE_STRING)" suffix
can be overridden with the AM_TESTSUITE_SUMMARY_HEADER variable.

* Bugs fixed

  - Python 3.10 version number no longer considered to be 3.1.

  - Broken links in manual fixed or removed, and new script
contrib/checklinkx (a small modification of W3C checklink) added,
with accompany target checklinkx to recheck urls.

  - install-exec target depends on $(BUILT_SOURCES).

  - valac argument matching more precise, to avoid garbage in DIST_COMMON.

  - Support for Vala in VPATH builds fixed so that both freshly-generated and
distributed C files work, and operation is more reliable with or without
an installed valac.

  - Dejagnu doesn't break on directories containing spaces.

* Distribution

  - new variable AM_DISTCHECK_DVI_TARGET, to allow overriding the
"make dvi" that is done as part of distcheck.

* Miscellaneous changes

  - install-sh tweaks:
. new option -p to preserve mtime, i.e., invoke cp -p.
. new option -S SUFFIX to attempt backup files using SUFFIX.
. no longer unconditionally uses -f when rm is overridden by RMPROG.
. does not chown existing directories.

  - Removed function up_to_date_p in lib/Automake/FileUtils.pm.
We believe this function is completely unused.

  - Support for in-tree Vala libraries improved.

also posted as:
  https://savannah.gnu.org/forum/forum.php?forum_id=9862
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFV0/xQDINEhtHupnf9n8ywAL7u4FAl+1+XEACgkQf9n8ywAL
7u5Q/xAAitfd7evm8xIT9AZjwRZ47F+kHV1Y3pIvNa8gWmOUcrpjBmtNXmV533O5
7j3N/nC365azhPtVots2UwdCKBq8KSfoQsil/GFH3hqFw0WfQnSXkr/lKoOxREu+
kQHsSbJeFDN1AoCeSmr8lgkmsfu1e41oqcOw2OTyJqUg74ufuEb5raTMOWtRiHXD
u3RHAYA8XRTVN17DftietFdZh0/YsW0+4eJZlWGpeojfAW569G/givJ1oKv4XkLW
ULtU8WI5H3ArUx39E7k+qSv2ZtgxrdYW3//h35mCmadN7n63rySuciyM2+cKUZx9
VDpQamhMSDunj0A5F+MQx4FI43a8bbEOWDQ/Kr5v5rmANuf+f3Tc2iCCQDQt3KBn
WQ1Ft8XyzykGClRLlXH/8B2t2K+w+1hM4t6zLqZqJ+4hEGq5esUGfPFIirh966Da
lAzi3aC0SQU1MtU1e+dp7C1H3Ebk+z6e/o642HG0AlpgYsv8aWrEbidSGbRsrbSt
R+xprPRsuvZ2u1j6UYsrj7tYM7WYYB/pkBYMQKTdcVbV94WYnNCzBaRxiEByGB9s
Ljil+9PFahltXlxCpC5aqssSFs4G3+1ytUQmh9P62Sg1pRywMlBykc0Tct7nyiKv
fUFBJ1VALj6jQRdL1lsGrQncetseElPMKA0+9YyqMPpx2g/fvRI=
=L/hM
-END PGP SIGNATURE-

Re: preparing for a new release

[Jim Meyering]

On Sun, Nov 15, 2020 at 6:52 PM Karl Berry  wrote:
>
> Hi Jim - (and thanks for the test runs and logs, Gavin)
>
>   make -k check TESTS='t/txinfo-no-clutter' \
> AM_TESTSUITE_MAKE="make -j$(( 2*$(nproc) + 1 ))"
>
> I know little about programming for parallel (auto)make, but I'm
> guessing that with the above invocation, the make commands inside the
> test are also being run in parallel?
>
> As far as I can see, this test is simply not set up to support that. It
> essentially runs, for every format being built by texi2dvi:
>   make FMT && make clean
>
> Thus it seems to me that one make clean could be cleaning the .dvi while
> the next make ps is trying to use it.
>
> And/or, maybe dependencies are missing. all-local is depending on
> "ps pdf dvi html", so I suppose they'll get spawned in parallel.  And the
> only dependency I'm seeing is the suffix rule, .dvi.ps, so maybe the
> purportedly intermediate .dvi is getting removed by one of the parallel
> makes?  So I tried adding
>
> .PRECIOUS: %.dvi
>
> to both Makefile.am's, and the fancy make command above then succeeded.
> Does that get around the problem for you?  Doesn't exactly seem like the
> best fix, though, since ordinarily one would want the intermediate file
> to be deleted. Maybe it would be cleaner to just force serialization of
> the makes inside this test? Is that possible?
>
> Further:
>
> 1) I am not smart enough to tell what's actually happening from the log
> since there's no indication of which make is doing what (and I can't
> even imagine how that could be indicated). How does one ever debug these
> things for sure?
>
> 2) I had not seen AM_TESTSUITE_MAKE before. I was running tests simply
> with make -j12 TARGET, and there the test does not fail -- not
> surprisingly, I guess, since then (I think) the makes inside the test
> are not being run in parallel.
>
> 3) I can't see why this is anything new. That test has not changed since
> 2012. The mentioned bug
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11146) describes the
> commit at that time as improving the test wrt parallelism.  Thus I
> surmise no one has ever tried with a parallel AM_TESTSUITE_MAKE before now.
>
> 4) I feel surprised that this parallelism does not cause trouble with
> other tests that involve suffix rules, like yacc or lex. I don't see
> .PRECIOUS being used in any other test, aside from precious.sh. But
> maybe no other test is doing quite what txinfo-no-clutter is.

Thanks for investigating. I've just fixed that with the attached (add
.NOTPARALLEL):


0001-tests-avoid-missing-.dvi-failure-with-parallel-tests.patch
Description: Binary data

preparing for a new release

[Jim Meyering]

Karl has made quite a few improvements, so I'm preparing to make a new
release. But first, I wanted to make the tests pass reliably also when
running them in parallel (the only way I run them, because otherwise,
they take way too long). I run a command like this:

make check AM_TESTSUITE_MAKE="make -j$(( 2*$(nproc) + 1 ))"

That evoked a surprising number of test failures. Note that these are
nondeterministic and depend on the amount of parallelism. All tests
may pass consistently on a system with 2 cores, yet some will fail
every time when nproc prints at least 6.

I've fixed a few of these failures, but here is still at least one
that I have not fixed: t/txinfo-no-clutter. In this case, running it
with no parallelism and by itself passes:
  make -k check TESTS='t/txinfo-no-clutter'
Yet running it with parallel make fails (I'm using make-4.3.90 built
from git, in case it matters):
  make -k check TESTS='t/txinfo-no-clutter' AM_TESTSUITE_MAKE="make
-j$(( 2*$(nproc) + 1 ))"

Not sure I'll work more on this today, so sharing: The attached log
shows that this fails when building that test's final "all" rule,
often because a .dvi file could not be found:

) localization,mv: cannot stat 'bar.dvi': No such file or directory

I've attached the four commits I'm about to push as well as that
individual testsuite.log, in case someone wants to help accelerate the
process.


0001-tests-avoid-failures-due-to-missing-ar-lib.patch
Description: Binary data


0002-tests-accommodate-an-ac_aux_dir-of-.-or.patch
Description: Binary data


0003-doc-fix-quoting-in-suggested-parallel-test-invocatio.patch
Description: Binary data


0004-tests-protect-against-parallel-false-failure.patch
Description: Binary data


test-suite.log
Description: Binary data

bug#14196: Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68

[Jim Meyering]

On Fri, Sep 4, 2020 at 4:38 PM Zack Weinberg  wrote:
> OK, after a quick investigation, the failure happens at configure time
> but the problem code belongs to automake.  Specifically,
> AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of
> $am_aux_dir/missing unconditionally:
>
> diff --git a/m4/missing.m4 b/m4/missing.m4
> index 6f742fb20..56c84fbf5 100644
> --- a/m4/missing.m4
> +++ b/m4/missing.m4
> @@ -21,12 +21,7 @@ AC_DEFUN([AM_MISSING_HAS_RUN],
>  [AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
>  AC_REQUIRE_AUX_FILE([missing])dnl
>  if test x"${MISSING+set}" != xset; then
> -  case $am_aux_dir in
> -  *\ * | *\*)
> -MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
> -  *)
> -MISSING="\${SHELL} $am_aux_dir/missing" ;;
> -  esac
> +  MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
>  fi
>  # Use eval to expand $SHELL
>  if eval "$MISSING --is-lightweight"; then
>
> This doesn't handle the possibility of $am_aux_dir containing
> backslash or double quote characters, but that's ok because
> AM_SANITY_CHECK will already have refused to run configure with either
> the current working directory or the source directory named like that.
> (An alternative patch would be to add ( ) to the set of characters
> rejected by AM_SANITY_CHECK.)

Thanks for investigating and patching.
I think this patch is the right way to go.
Otherwise, I suspect we'd have to make AM_SANITY_CHECK disallow not
only parentheses, but also at least these !?*[]

While looking at this, I wondered... why are the inner quotes double quotes?
I.e., we might as well use single quotes. Slightly cleaner, too, since
no backslash is required for them:
+ MISSING="\${SHELL} '$am_aux_dir/missing'" ;;

Re: problems with "make install" directory permissions

[Jim Meyering]

On Mon, Jul 27, 2020 at 3:03 PM Paul Eggert  wrote:
>
> 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. :-)

>From what I recall, we deliberately avoid making installed things
group-writable because that would induce a security risk in
installations where more than one user is in the same default group.

If I install in such an environment (and don't override the group), I
don't want a peer to be able to modify what I've just installed.

bug#11745: the new test-suite summary is confusing

[Jim Meyering]

On Mon, Jun 1, 2020 at 6:46 PM Karl Berry  wrote:
> Hi Alexandre and all - regarding
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11745 (12 years ago, oh well).
>
> I upgraded to Automake 1.12.1 to discover the each of these test-suite
> [directories] now displays a huge summary like:
> 
> 
> Testsuite summary for spot 0.9.1a
> ...
> The above in definitely *not* a testsuite summary for
> the project, it's only a test summary for one directory.
>
> Agreed, but:
>
> I think the easiest fix would be to change the header to just
> "Testsuite summary", without mentioning the package.
>
> I don't think that's the right fix. In TeX Live, we have many different
> packages, all in one Automake tree, and if every testsuite summary just
> said "TeX Live", it would be difficult to discern what the summary was
> reporting on. That is, the TL make check output starts like this:
> Testsuite summary for Kpathsea 6.3.3/dev
> ..
> Testsuite summary for zlib (TeX Live) 1.2.11
> ..
> Testsuite summary for lua53 (TeX Live) 5.3.5
>
> If all of those just said "TeX Live", it wouldn't be good.
>
>
> I don't think we should change the default form of the Automake header
> line at this late date, since some packages (and plenty of AM's own
> tests) might well be expecting what's currently output.
>
> So I propose to define a new variable in lib/am/check.am:
> AM_TESTSUITE_SUMMARY_HEADER = " for $(PACKAGE_STRING)"
> so the default is unchanged.

Thanks, Karl!
This looks great. Only one minor suggestion: to use single quotes
there, rather than double:

  AM_TESTSUITE_SUMMARY_HEADER = ' for $(PACKAGE_STRING)'

so that the replacement value is less likely to require additional escaping.

bug#8289: distcheck and make dvi

[Jim Meyering]

On Sun, May 17, 2020 at 9:44 AM Karl Berry  wrote:
> I've attempted to construct a patch [attached] following my own
> suggestion :), to create a new variable to allow overriding the "make
> dvi" which is done as part of distcheck with another target. I named the
> variable AM_DISTCHECK_DVI_TARGET (if something else seems better,
> fine). The actual functional change is one line, in distdir.am:
>
> - && $(MAKE) $(AM_MAKEFLAGS) dvi \
> + && $(MAKE) $(AM_MAKEFLAGS) $(AM_DISTCHECK_DVI_TARGET) \
>
> All else is overhead. My biggest question is about naming. I simply
> AM_DISTCHECK_DVI_TARGET = dvi
> for the default also in distdir.am. This necessitated adding it to the
> list of AM_* variables allowed to be defined, in Variable.pm:
> -  (AM_MAKEINFOHTMLFLAGS => 1,
> +  (AM_DISTCHECK_DVI_TARGET => 1,
> +   AM_MAKEINFOHTMLFLAGS => 1,
>
>
> Would it be better to use a separate variable, like
> am__distcheck_dvi_target? But then how to know if the user has defined
> AM_DISTCHECK_DVI_TARGET?
>
> Of course any and all comments welcome ... Jim? Anyone? --thanks, karl.

Hi Karl,
That looks fine to me.
Sorry it took so long to reply.

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

[Jim Meyering]

On Sat, May 9, 2020 at 8:05 PM Harald van Dijk  wrote:
> On 10/05/2020 02:10, Karl Berry wrote:
> > +Although we would like to remove this function from Automake, since it's
> > +not used, that would break older versions of Autoconf, which seems
> > +gratuitious. So we leave it, unchanged.
>
> Autoconf has its own copy of this function, so why would it be affected
> by the removal of the function from Automake?

Good point. You're right:

> ac$ git grep -n sub.up_to_date_p
> lib/Autom4te/FileUtils.pm:190:sub up_to_date_p ($@)

in that removing it from automake should not impact any existing
installation of autoconf. However, autoconf's lib/Autom4te hierarchy
is sync'd from automake, so we would still need to make an adjustmake
to autoconf before its next sync.

So fine to remove from automake after all. Good!

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

[Jim Meyering]

On Sat, May 9, 2020 at 6:10 PM Karl Berry  wrote:
>
> Probably best to leave it, as is, and mark it as known-to-be-unused at
> least via comment.
>
> How does the text below look for an explanation?

Very good! Thanks for dealing with this.
Two suggestions below.

> (By the way, I noticed that FileUtils.pm, unlike the other *.pm in
> lib/Automake, doesn't have an =over 4 ... =back around all the other
> items, causing pod2text to complain. I'll fix that too unless there is
> some magical reason for it.)

Sounds fine to fix that. Thanks!

> --- a/lib/Automake/FileUtils.pm
> +++ b/lib/Automake/FileUtils.pm
> @@ -181,7 +181,20 @@ sub update_file ($$;$)
>
>  =item C
>
> -Is C<$file> more recent than C<@dep>?
> +Is C<$file> strictly more recent than C<@dep>?
> +If mtimes are equal, returns true.
> +
> +This function is not used anywhere in Automake.  Where it is used is in

Perhaps s/Where it is used is in/However, it @emph{is} used in/

also, s/subsecond/sub-second/ to pacify spell-checkers :-)

> +C, which is part of Autoconf.  And its use there poses a
> +problem with respect to subsecond timestamps, as discussed at
> +L
> +(thread continues into May).  The best approach seems to be to leave this
> +function alone, and have C use a different test, one which is
> +not part of Automake.
> +
> +Although we would like to remove this function from Automake, since it's
> +not used, that would break older versions of Autoconf, which seems
> +gratuitious. So we leave it, unchanged.

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

[Jim Meyering]

On Mon, Apr 20, 2020 at 6:13 PM Karl Berry  wrote:
> the command that updates autom4te.cache/traces.0 does not modify
> configure.ac at the same time.
>
> No argument for that specific case. But looking at the change in
> isolation:
>
> -  if ($mtime < mtime ($dep))
> +  if ($mtime <= mtime ($dep))
> {
>   verb "up_to_date ($file): outdated: $dep";
>
> it says that a dependency with the same mtime as the target will now be
> "outdated", instead of being up to date. This just seems contrary to the
> standard behavior in make (and wherever else), and what would generally
> be expected.
>
>   998 Autom4te::C4che->load ($icache_file)
>   999   if -f $icache && mtime ($icache) > mtime ($0);
>
> I agree it's inconsistent with the current up_to_date_p.
>
> I understand some change needs to be made for autom4te to work
> consistently with subsecond timestamps. I have no problem with that, but
> autom4te is part of autoconf, not automake, as you know.
>
> So ... the change that comes to my mind is to avoid using up_to_date_p
> in autom4te. There could be a new function, or since it is apparently
> only used at one place (line 923), just write out the mtime tests as
> needed, as you cited above. Seems like the mtime test could be part of
> the   while ($_ = $deps->getline)  loop just above the present call to
> up_to_date_p.

I agree that we should break this dependency: either way would work
for me: new function or inline.

> As for the up_to_date_p function, it is not used in automake at all. As
> far as I can see, it is only used in autom4te.  But perhaps it is used
> entirely outside automake/autoconf by other random (user?) programs.
> I doubt it, but can any of us be sure? And if it does have outside users,
> that would be more reason not to change it. Alternatively, if we're sure
> there are no outside users, my proposal would be to delete it, as unused.

I confess that I like the idea of removing it from automake, since no
search I ran found any other use of it, but that would render the next
automake unusable with any older autoconf that still requires it. We
could of course mandate a newer version of autoconf that doesn't need
it, but even that could probably go awry...

Probably best to leave it, as is, and mark it as known-to-be-unused at
least via comment.
Thanks for working on this.

automake-1.16.2 released [stable]

[Jim Meyering]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is to announce automake-1.16.2, a stable release.

There have been 38 commits by 12 people in the two years
(almost to the day) since 1.16.1.  Special thanks to Karl Berry
for doing a lot of the recent work preparing for this release.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Bruno Haible (1)
  Gavin Smith (1)
  Giuseppe Scrivano (1)
  Jim Meyering (5)
  Karl Berry (12)
  Libor Bukata (1)
  Lukas Fleischer (2)
  Mathieu Lirzin (8)
  Paul Eggert (4)
  Paul Hardy (1)
  Paul Osmialowski (1)
  Vincent Lefevre (1)

Jim [on behalf of the automake maintainers]
==

Here is the GNU automake home page:
http://gnu.org/s/automake/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=automake.git;a=shortlog;h=v1.16.2
or run this command from a git-cloned automake directory:
  git shortlog v1.16.1..v1.16.2

Here are the compressed sources:
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.xz (1.5MB)
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.gz (2.3MB)

Here are the GPG detached signatures[*]:
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.xz.sig
  https://ftp.gnu.org/gnu/automake/automake-1.16.2.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify automake-1.16.2.tar.xz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 7FD9FCCB000B

and rerun the 'gpg --verify' command.

==
NEWS

* New features added

  - add zstd support and the automake option, dist-zstd.

* Miscellaneous changes

  - automake no longer requires a @setfilename in each .texi file

* Bugs fixed

  - When cleaning the compiled python files, '\n' is not used anymore in the
substitution text of 'sed' transformations.  This is done to preserve
compatibility with the 'sed' implementation provided by macOS which
considers '\n' as the 'n' character instead of a newline.
(automake bug#31222)

  - For make tags, lisp_LISP is followed by the necessary space when
used with CONFIG_HEADERS.
(automake bug#38139)

  - The automake test txinfo-vtexi4.sh no longer fails when localtime
and UTC cross a day boundary.

  - Emacsen older than version 25, which require use of
byte-compile-dest-file, are supported again.

Also posted as:
  https://savannah.gnu.org/forum/forum.php?forum_id=9706
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEFV0/xQDINEhtHupnf9n8ywAL7u4FAl52thEACgkQf9n8ywAL
7u60Bg/+NgLD/qLC2ZpoMrDYZa7UJfnLdQwtJRHx8yTP6xncY1n+T8PDjM5Q/Ihh
daUWHii4TYapNrBO0xJP//bMkH0ubwvfLCHaZtpBfLL00B25IE8uIcj+1S40LDdo
nrmJARQAqFmWLks4pDl82LHOnXAjzB2hBzN1msl8IEyWTPoAT3t0myQJpt6TFKUo
otLp+DH6MBplgXZjn8ZW1w9ElWhAVo6k20o3DXs0wza1+pEs2Kk0JdJwC1istlMS
hszuOcq8OTOzBhBaK93QEc2XQSojPa729pufPPpAtsWj6Z8K3VbFz0ASoSR6sW4G
x7ZGz2p9zACUuhTXW4hyAK3//iBSeM3A+oY8mq1OhHVFGw0y5UYCMDc5Np4DHiKD
WKfn5+HuttfEKPtye2bH5QZYFaHaKelsxVmYtTkxvql0fWegCN6V3jecxh3RIuWl
F6i8qV//tOp6f0rRdIRmJPY41unF3kubfu4CvoDvZnTTRZ/WRaQ+WJ4q1HVrjzu4
K6Fb/H7PQBq8/QwKqiswCj42aOmP2oG//LSXXmcIIywqWAhieldMhQdUq2IWlzIs
N7FbxoAegGJCpWOJ/5fcn4UR5zL8qBlDRQcVitu6cai3CxWwrIQm6TUPqxuiFQ87
tve8ejvSpFT7EjKaaQUHWhLk3enf8+SfNu9ucgZA2mq0Gp/cvH0=
=Lt5J
-END PGP SIGNATURE-

Re: dependency tracking error message

[Jim Meyering]

On Thu, Feb 13, 2020 at 6:40 PM Karl Berry  wrote:
> Looking at the automake-patches that have accumulated, I saw one to
> improve the error message if dependency tracking fails. Copied below.
>
> It seems generally sensible to me, though I would change the wording a
> little, and there is a spurious "the", so, revising the proposed text:
>
>   AC_MSG_FAILURE([Something went wrong bootstrapping makefile fragments
>   for automatic dependency tracking.  If GNU make was not used, consider
>   re-running the configure script with MAKE="gmake" (or whatever is
>   necessary).  You can also try re-running configure with the
>   '--disable-dependency-tracking' option to at least be able to build
>   the package (albeit without support for automatic dependency tracking).])
>
> Confirm/deny? Further suggestions? --thanks, karl.

Thanks. Looks fine.

I prefer to use the short form of bug URLs, e.g., this:
  https://bugs.gnu.org/35848
rather than this:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848

> >From 040f4cc6b8300af4812549d69b07926e5423988a Mon Sep 17 00:00:00 2001
> From: Libor Bukata 
> Date: Thu, 23 May 2019 12:31:31 +0200
> Subject: [PATCH] Improve the error message when the dependency tracking fails

s/when the/when/

> The dependency tracking may fail with a non-intuitive error
> that "Something went wrong ..." if the package expects
> GNU make to process its Makefile.am files and other make
> implementation is used by default (e.g., Solaris make).
> This patch adds a hint to the error message that the user
> may try to specify GNU make command as a configure argument.
>
> Related bug with discussion:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35848
>
> * m4/depout.m4: Added a hint to the error message.

s/Added/Add/

Re: t/aclocal-print-acdir.sh at installcheck and AUTOMAKE_UNINSTALLED

[Jim Meyering]

On Mon, Feb 3, 2020 at 6:23 PM Karl Berry  wrote:
> The aclocal-print-acdir.sh test fails at the make installcheck step of
> make distcheck (it succeeds in the normal make check, and it succeeds at
> the make check of make distcheck; only fails in the make installcheck).
>
> This is because AUTOMAKE_UNINSTALLED is (correctly) set in the
> environment at that point, which causes aclocal-1.16 --print-ac-dir
> to forcibly return the empty string, which does not match the expected
> acdir string:
>
>   + aclocal-1.16 -Werror --print-ac-dir
>
>   test "$($ACLOCAL --print-ac-dir)" = "$am_system_acdir"
>   ++ aclocal-1.16 -Werror --print-ac-dir
>   + test '' = /u/karl/gnu/src/akarl/automake-1.16a/_inst/share/aclocal
>   am_exit_trap $?
>   + am_exit_trap 1
>
> Per this bit in the aclocal-1.16 Perl script:
>
>   if (exists $ENV{"AUTOMAKE_UNINSTALLED"})
> {
>   @automake_includes = ();
>   @system_includes = ();
> }
>
> (The --print-ac-dir option simply prints the value of @system_includes.)
>
> So, if I unset AUTOMAKE_UNINSTALLED in the test, it works:
> test "$am_running_installcheck" = yes && unset AUTOMAKE_UNINSTALLED || :
>
> Since this test is intended to check exactly a value that only is set
> normally in an installation, that seems like a reasonable thing to do.

That sounds eminently reasonable.

I don't recall ever knowing about this AUTOMAKE_UNINSTALLED envvar, so
you are now the sole active contributor who has plumbed those depths
:-)

> But I am not sure. Jim, anyone with more experience, can you confirm/deny?
>
> Thanks,
> Karl
>
> P.S. This also fails for me if I run make installcheck after
> building the released automake-1.16.
>
> P.P.S. There are two other tests, print-libdir and aclocal-print-acdir,
> which also fail at the make installcheck step of make distcheck, and not
> sooner. Unfortunately they are not solved by unsetting
> AUTOMAKE_UNINSTALLED, though I think the problem is generally similar.

Good!

Re: [PATCH] lint: make syntax-check same as maintainer-check.

[Jim Meyering]

On Sun, Jan 19, 2020 at 6:25 PM Karl Berry  wrote:
> Next trivial patch: make syntax-check an alias for maintainer-check,
> since so many other packages recognize syntax-check, as Jim has
> noted. Wdyt? -k

Perfect. Thanks!

Re: [PATCH] tests: use find+rm, not perl, to remove temporary directories.

[Jim Meyering]

On Sat, Jan 18, 2020 at 6:11 PM Karl Berry  wrote:
> Here's my proposed patch to use chmod and rm -rf (again), instead of
> deltree.pl.
>
> In the verbose output in case of failure, I split the difference and
> added a terminating line "end ls ...", but did not prefix the ls
> output. While I was testing, that seemed the most usable.

Thanks, Karl. That looks fine.
In the log, please use the short bug URL:
  https://debbugs.gnu.org/39078
rather than:
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39078

bug#39078: Path.pm change -> deltree.pl -> t/uninstall-fail failure

[Jim Meyering]

On Sun, Jan 12, 2020 at 6:41 PM Karl Berry  wrote:
>
> Regarding the new failure of Path.pm:rmtree to do removals, here is the
> change I had in mind to use chmod and rm instead. The previously-"ERROR"
> tests (uninstall-fail and instspc) work for me with this change.
>
> Before I bother spending time on all the related overhead changes, any
> objections, improvements, comments on this approach?
>
> The rest of the patch is unrelated to the functional change: checking
> for any of the elements existing after the purported removal. In my
> testing I found it useful for this to be reported, and the abort to
> occur, right away.
>
> Then, the recursive ls report on failure might be overkill, but I found
> it useful to understand the failing situation, so here it is for
> consideration. (I guess it would be better to prepend the prefix to
> every line of the ls output, which would be easy enough.)  --thanks, karl.

Hi Karl,
I like your patch. With our without prefixes.
Thanks for working on this!

Re: [PATCH] tests: use skip_ consistently.

[Jim Meyering]

On Wed, Jan 8, 2020 at 2:03 PM Karl Berry  wrote:
>
> how about this instead? (feels a little like removing a double negative):
>   test "$EMACS" = t && EMACS=emacs
>
> Indeed, that looks a lot more natural, but as far as I can see, the
> problem is Automake's pervasive use of set -e.
>
> sh-4.2$ test "$FOO" = t && FOO=foo
> sh-4.2$ echo $?
> 1

Oh yeah. Then this, I guess:

  test "$EMACS" = t && EMACS=emacs || :

or "|| true" as you said.

Re: [PATCH] tests: use skip_ consistently.

[Jim Meyering]

On Tue, Jan 7, 2020 at 6:25 PM Karl Berry  wrote:
> I belatedly noticed that I should have used skip_ instead of exit 77
> in my new too-old-Emacs test. Plus found a wrong occurrence of just
> "skip" without the _ in uninstall-fail.sh. Look ok?

Good catches both.

I noticed this added line:
  test "$EMACS" != t || EMACS=emacs
how about this instead? (feels a little like removing a double negative):
  test "$EMACS" = t && EMACS=emacs

> (uninstall-fail has more failures in the case of a newer File::Path, due
> to changes in rmtree as used in deltree.pl, but that'll be another day.)

Thanks!

Re: [PATCH] tests: Correctly simulate no emacs in t/nobase-nodist.sh

[Jim Meyering]

On Sun, Jan 5, 2020 at 6:22 PM Karl Berry  wrote:
> Typo in export command in one test. Barring problems, will push in a day
> or two. --thanks, karl.

Good catch.
Thanks. That was introduced back in a 2011 commit, v1.11-449-g0b7d3cbc9

Re: byte compilation in older emacs [patch]

[Jim Meyering]

On Fri, Jan 3, 2020 at 6:13 PM Karl Berry  wrote:
>
> Sigh. I failed to note that vc-dwim did not dwim; my summary first line
> was once again not recognized. (And I guess I should update the date.)
> I'll figure that out before pushing, but anyway, the content of the
> patch is what really needs review. Here's the actual ChangeLog entry as
> written ... -k
>
> 2020-01-03  Karl Berry  
>
> automake: Support byte compilation in older Emacsen
>
> * lib/am/lisp.am (am__emacs_byte_compile_setup) [FIRST]: define
> new make variable, to use byte-compile-dest-file-function if
> available, else byte-compile-dest-file.
> (.el.elc): use it.
> * t/lisp-loadpath.sh: skip test if emacs version is <= 23,
> since their -L ordering is backwards.
> * NEWS: update.

Thank you for doing that. It looks fine to me. One request:

In this:
+emacs_major=$(${EMACS-emacs} --version | sed -e 's/.* //' -e 's/\..*$//' -e 1q)

please use this same-functionality sed command. I prefer to eliminate
such uses of -e and to reduce quote count:
  sed 's/.* //;s/\..*$//;1q'

FYI: fixing "maintainer-check" tests

[Jim Meyering]

I've just fixed some FP nits:

[PATCH] maint: make maintainer-check tests pass

* maintainer/syntax-checks.mk (sc_sanity_gnu_grep): Remove
NUL byte from grep output, to avoid shell diagnostic about
"NUL byte suppressed from expansion."
(automake_diff_no, aclocal_diff_no): Adjust number of expected
diff lines.


maint.diff
Description: Binary data

Re: t/txinfo-vtexi4.sh and timezone failure

[Jim Meyering]

On Fri, Dec 20, 2019 at 6:15 PM Karl Berry  wrote:
>
> The automake test t/txinfo-vtexi4.sh failed when localtime and UTC were
> on different days, resulting in the GREPDATE for the @UPDATED@ string
> not matching (among possible others).
>
> mdate-sh always uses TZ=UTC0. This tiny change makes the test do the
> same thing.
>
> I wondered if there were other tests that might have the same problem,
> e.g., if TZ would be better set in test-init.sh (although granted this
> was the only one failing). However, install-sh-option-C.sh is the only
> other test that was setting TZ, and I didn't see others invoking date,
> either. So Jim and I figured just patching vtexi4 is reasonable.
>
> Unrelated but so trivial did not at all seem worth separating: the doc
> in vtexi4.sh referred to itself when it didn't mean to.
>
> Any comments or suggestions before I attempt to push this? --thanks, karl.

Good one. Thank you for tracking that down.
When I applied that, "git am FILE" warned about this:
.git/rebase-apply/patch:14: trailing whitespace.

So please amend that to remove the trailing space in NEWS.

bug#38139: Fwd: Likely bug: generating tags with Emacs Lisp sources present

[Jim Meyering]

On Mon, Nov 11, 2019 at 6:55 PM Luca Saiu  wrote:
>
> On 2019-11-10 at 14:24 +0100, Luca Saiu wrote:
>
> > using lisp_DATA rather than lisp_LISP prevents the misbehavior.
>
> But, incidentally, using lisp_DATA also prevents tag generation from the
> Emacs Lisp sources.

Thanks to both of you. Karl wrote the attached fix, and I will push it soon:


karl.diff
Description: Binary data

Re: [PATCH] dist: add dist-zstd option

[Jim Meyering]

On Sat, Nov 16, 2019 at 12:23 PM Giuseppe Scrivano  wrote:
> Jim Meyering  writes:
> > On Mon, Nov 11, 2019 at 12:35 PM Giuseppe Scrivano  
> > wrote:
> >> Hi Jim,
> >>
> >> Jim Meyering  writes:
> >>
> >> > On Fri, Oct 4, 2019 at 8:03 AM Giuseppe Scrivano  
> >> > wrote:
> >> >> add support for using the zstd compression algorithm.
> >> >
> >> > Hi Giuseppe,
> >> > Thank you for that patch.
> >> > I've adjusted it and propose the attached, which makes these changes:
> >> > - add tests
> >> > - that exposed the need for a correction, s/-d/-dc/ in distdir.am
> >> > - extend documentation
> >> > - use the 3-byte suffix, .zst, not .zstd
> >> > - use -19 as the default compression level
> >> >
> >> > We must use -19 as the default, not the aggressive --ultra -22 -- the
> >> > package maintainer can always override with ZSTD_OPT if they know all
> >> > clients will always have sufficient memory. In the early days, some
> >> > reported failure to decompress a "xz -9e"-compressed coreutils tarball
> >> > on tiny-memory routers. Like zstd's --ultra settings, xz's -9 requires
> >> > more RAM when DEcompressing -- so automake defaults to xz's "-e" (use
> >> > extra CPU only) and used -e8 for coreutils
> >> > (https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.15-61-gc1d07237a):
> >> > i.e., still require 32MiB more RAM, but not the 64MiB that "-9" would
> >> > require.
> >> >
> >> > Cc'd the zstd author, Yann Collet, in case he'd like to add something.
> >> >
> >> > Giuseppe, please re-review this diff and its updated commit log.
> >>
> >> is there anything more holding the patch?
> >
> > Sorry about the delay.
> > On suggestion from Yann, I propose one additional change. Barring
> > objection, I will push the combined result tomorrow.
>
> The new patch looks good to me.

Pushed.

Re: [PATCH] dist: add dist-zstd option

[Jim Meyering]

On Mon, Nov 11, 2019 at 12:35 PM Giuseppe Scrivano  wrote:
> Hi Jim,
>
> Jim Meyering  writes:
>
> > On Fri, Oct 4, 2019 at 8:03 AM Giuseppe Scrivano  
> > wrote:
> >> add support for using the zstd compression algorithm.
> >
> > Hi Giuseppe,
> > Thank you for that patch.
> > I've adjusted it and propose the attached, which makes these changes:
> > - add tests
> > - that exposed the need for a correction, s/-d/-dc/ in distdir.am
> > - extend documentation
> > - use the 3-byte suffix, .zst, not .zstd
> > - use -19 as the default compression level
> >
> > We must use -19 as the default, not the aggressive --ultra -22 -- the
> > package maintainer can always override with ZSTD_OPT if they know all
> > clients will always have sufficient memory. In the early days, some
> > reported failure to decompress a "xz -9e"-compressed coreutils tarball
> > on tiny-memory routers. Like zstd's --ultra settings, xz's -9 requires
> > more RAM when DEcompressing -- so automake defaults to xz's "-e" (use
> > extra CPU only) and used -e8 for coreutils
> > (https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.15-61-gc1d07237a):
> > i.e., still require 32MiB more RAM, but not the 64MiB that "-9" would
> > require.
> >
> > Cc'd the zstd author, Yann Collet, in case he'd like to add something.
> >
> > Giuseppe, please re-review this diff and its updated commit log.
>
> is there anything more holding the patch?

Sorry about the delay.
On suggestion from Yann, I propose one additional change. Barring
objection, I will push the combined result tomorrow.


automake-zstd-clevel.diff
Description: Binary data

Re: [PATCH] dist: add dist-zstd option

[Jim Meyering]

On Fri, Oct 4, 2019 at 8:03 AM Giuseppe Scrivano  wrote:
> add support for using the zstd compression algorithm.

Hi Giuseppe,
Thank you for that patch.
I've adjusted it and propose the attached, which makes these changes:
- add tests
- that exposed the need for a correction, s/-d/-dc/ in distdir.am
- extend documentation
- use the 3-byte suffix, .zst, not .zstd
- use -19 as the default compression level

We must use -19 as the default, not the aggressive --ultra -22 -- the
package maintainer can always override with ZSTD_OPT if they know all
clients will always have sufficient memory. In the early days, some
reported failure to decompress a "xz -9e"-compressed coreutils tarball
on tiny-memory routers. Like zstd's --ultra settings, xz's -9 requires
more RAM when DEcompressing -- so automake defaults to xz's "-e" (use
extra CPU only) and used -e8 for coreutils
(https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.15-61-gc1d07237a):
i.e., still require 32MiB more RAM, but not the 64MiB that "-9" would
require.

Cc'd the zstd author, Yann Collet, in case he'd like to add something.

Giuseppe, please re-review this diff and its updated commit log.


automake-zstd.diff
Description: Binary data

Re: bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

[Jim Meyering]

On Sat, Sep 14, 2019 at 5:35 AM Gavin Smith  wrote:
> On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering  wrote:
> >
> > Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> > Another reference to the problem: http://bugs.gnu.org/36921
> >
> > In the attached (in Gavin's name), I've added a NEWS entry and
> > adjusted the ChangeLog entry. Will push in a day or so if no comment.
>
> Thanks for taking the time to look at this.

Oh! Thanks for the reminder. I've just pushed that.

bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

[Jim Meyering]

On Sat, Sep 14, 2019 at 5:35 AM Gavin Smith  wrote:
> On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering  wrote:
> >
> > Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
> > Another reference to the problem: http://bugs.gnu.org/36921
> >
> > In the attached (in Gavin's name), I've added a NEWS entry and
> > adjusted the ChangeLog entry. Will push in a day or so if no comment.
>
> Thanks for taking the time to look at this.

Oh! Thanks for the reminder. I've just pushed that.

[PATCH] automake: do not require @setfilename in Texinfo files

[Jim Meyering]

Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
Another reference to the problem: http://bugs.gnu.org/36921

In the attached (in Gavin's name), I've added a NEWS entry and
adjusted the ChangeLog entry. Will push in a day or so if no comment.


automake-relax-setfilename.diff
Description: Binary data

bug#36921: [PATCH] automake: do not require @setfilename in Texinfo files

[Jim Meyering]

Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201
Another reference to the problem: http://bugs.gnu.org/36921

In the attached (in Gavin's name), I've added a NEWS entry and
adjusted the ChangeLog entry. Will push in a day or so if no comment.


automake-relax-setfilename.diff
Description: Binary data

Re: [PATCH] ar-lib: Fix for MSVC 14.

[Jim Meyering]

On Wed, Jul 3, 2019 at 6:52 PM Bruno Haible  wrote:
> Hi,
>
> When building GNU gettext HEAD (0.20.1+) with MSVC 14, the creation of
> libtextstyle.la fails, because it can't extract the members of several
> sub-libraries (*.lib files). The reason is that the
>   lib -NOLOGO -LIST some.lib
> lists the members, one per line, with a CR/LF as line terminator.
> The file names given in subsequent commands to
>   lib -NOLOGO -EXTRACT...
> thus end in a CR, and 'lib' does not unpack these members, complaining:
>   LINK : warning LNK4014: cannot find member object 
> libxml/.libs/rpl_la_tree.obj^M
>
> The fix is simple: Remove the CRs in the pipe.

Hi Bruno,
That looks fine. Please push.

Thank you.

Re: __pycache__ directories and distcleancheck

[Jim Meyering]

Thanks for the report. Would you please create a minimal set-up to
demonstrate the problem? That will probably expedite a proper fix.

On Wed, Jun 13, 2018, 11:56 Adam Mercer  wrote:

> Hi
>
> We've recently updated our code to support Python3 and are running
> into a problem with __pycache__ directories being leftover in the
> build directory after a distclean. Is the appropriate thing to do here
> simply to list the files in DISTCLEANFILES or is there a better way?
>
> Cheers
>
> Adam
>
>

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Dec 11, 2017 at 11:03 AM, Jim Meyering <j...@meyering.net> wrote:
> On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris <r...@gnu.org> wrote:
>>
>> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
>>
>>> However, I don't see how "-f batch-byte-compile" can be used when
>>> the .elc file must be created in a directory separate from the one
>>> containing the .el file.
>>
>> I meant, instead of reinventing the wheel with this part:
>>
>>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>>
>> Example:
>>
>> mkdir /tmp/foo /tmp/bar
>> echo '(message "hi")' > /tmp/foo/foo.el
>> emacs --batch \
>>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
>> "/tmp/bar/foo.elc"))' \
>>  -f batch-byte-compile /tmp/foo/foo.el
>>
>> -> generates /tmp/bar/foo.elc
>>
>> batch-byte-compile exists since forever.
>
> Thank you. That looks better, indeed. I will see if I can adapt the
> automake patch accordingly.

I've done that and will push the attached to master later today.
Thanks,
Jim
From e56d637494d4e5c9f0cca0d6417b21d683eb7d6f Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Wed, 22 Nov 2017 21:07:29 -0800
Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer

In May of 2017, emacs.master support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
The removed functionality has been restored for Emacs-26, albeit with
dissuasive diagnostics warning about the imminent removal of this
functionality.  It will be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function, rather
than byte-compile-dest-file.  Also, use "-f batch-byte-compile '$<'"
rather than open-coding it, as suggested by Glenn Morris.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention this problem.
---
 NEWS  |  5 +
 lib/am/lisp.am|  6 +++---
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 6d8b9d248..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -124,6 +124,11 @@ New in ?.?.?:
   - The time printed by 'mdate-sh' is now using the UTC time zone to support
 the reproducible build effort.  (automake bug#20314)

+  - The elisp byte-compilation rule now uses byte-compile-dest-file-function,
+rather than byte-compile-dest-file, which was obsoleted in 2009. We expect
+that Emacs-26 will continue to support the old function, but will complain
+loudly, and that Emacs-27 will remove support for it altogether.
+
 

 New in 1.15.1:
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..91a0e0516 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -30,7 +30,7 @@ endif %?INSTALL%
 ## The destination file is normally determined by appending "c" to the
 ## input (which would erronously put it in $(srcdir) in VPATH builds),
 ## so we override that, too.
-   if test "$(EMACS)" != "no"; then \
+   if test '$(EMACS)' != no; then \
  am__dir=. am__subdir_includes=''; \
  case $@ in */*) \
am__dir=`echo '$@' | sed 's,/[^/]*$$,,'`; \
@@ -41,8 +41,8 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
-   --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
+   --eval '(setq byte-compile-dest-file-function (lambda (_) "$@"))' \
+   -f batch-byte-compile '$<'; \
else :; fi


diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris <r...@gnu.org> wrote:
>
> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
>
>> However, I don't see how "-f batch-byte-compile" can be used when
>> the .elc file must be created in a directory separate from the one
>> containing the .el file.
>
> I meant, instead of reinventing the wheel with this part:
>
>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>
> Example:
>
> mkdir /tmp/foo /tmp/bar
> echo '(message "hi")' > /tmp/foo/foo.el
> emacs --batch \
>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
> "/tmp/bar/foo.elc"))' \
>  -f batch-byte-compile /tmp/foo/foo.el
>
> -> generates /tmp/bar/foo.elc
>
> batch-byte-compile exists since forever.

Thank you. That looks better, indeed. I will see if I can adapt the
automake patch accordingly.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Wed, Nov 29, 2017 at 12:17 PM, Glenn Morris  wrote:
> The obsolete bytecomp feature is back as of Emacs 9964db4.

Thanks, I noticed when that was restored, but have been a way for a while.

> BTW, why doesn't lisp.am use the standard "-f batch-byte-compile"
> method of producing .elc files?
>
> Your two issues that affected only automake illustrate that the way
> automake generates .elc files is different to the vast majority of
> Emacs projects.

Thanks for the suggestion, Glenn. However, I don't see how "-f
batch-byte-compile" can be used when the .elc file must be created in
a directory separate from the one containing the .el file. I think
automake generates code the way it does because GNU coding standards
mandate that one be able to build from a read-only hierarchy of
sources (think read-only media).

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

[Jim Meyering]

On Tue, Nov 28, 2017 at 8:35 PM, Nick Bowler <nbow...@draconx.ca> wrote:
> On 2017-11-28 18:13 -0800, Jim Meyering wrote:
>> On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote:
>> > The Automake manual unequivocally states that BUILT_SOURCES files are
>> > generated only when running 'make all', 'make check' or 'make install'.
>> >
>> > So if they are going to be generated on 'make dist' as well, then the
>> > manual needs a corresponding update.
>>
>> Hi Nick,
>> Thanks for the suggestion, but I do not think it is desired. "make
>> dist" is already defined as building everything that goes into the
>> distribution tarball, and that implies it must also build anything
>> (e.g., from BUILT_SOURCES) that happens to be required to do that.
>
> I agree that it *should* but not that it *must*, because BUILT_SOURCES
> explicitly (by design) bypasses the usual prerequisite mechanisms.
>
> If you use normal prerequisites instead of BUILT_SOURCS everything
> works just fine wrt. distribution, of course, and is the approach I
> would personally recommend in all cases.
>
>> Perhaps more importantly, this is an implementation detail that feels
>> like it should not be made part of the contract that the documentation
>> provides ...
>
> But now with the change applied, as it stands the documentation is
> simply wrong.  For example, this passage from the manual (§9.4 Built
> Sources):
>
>   "... BUILT_SOURCES is honored only by ‘make all’, ‘make check’ and
>   ‘make install’."
>
> is no longer true.  This error can be corrected without explicitly
> documenting the new behaviour, for example by making the list of
> targets non-exhaustive in nature.
>
> Perhaps something like:
>
>   ... BUILT_SOURCES is honored only by certain targets, including ‘make
>   all’, ‘make check’ and ‘make install’.

Thanks for keeping us honest.
That sounds reasonable. Send a patch?

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

[Jim Meyering]

On Tue, Nov 28, 2017 at 12:01 PM, Mathieu Lirzin  wrote:
> Hello Jim,
...
>>
>> Here's the patch I expect to push to master:
...
>
> OK to push.

Thanks. Pushed.
I have also removed the micro branch.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Tue, Nov 28, 2017 at 2:23 PM, Glenn Morris <r...@gnu.org> wrote:
> Jim Meyering wrote:
>
>> Remember: this arises only in a non-srcdir build. That means build
>> artifacts end up being written into the mostly-empty current directory
>> hierarchy, which does not have copies of the sources. Installation
>> processes will continue to copy both .el and .elc files into place.
>
> Oh, so you only split .el and .elc up while building, but they get
> installed into the same place? That's not so bad, though it is, eg, not
> something that Emacs supports in its own build process (in non-srcdir
> builds, .elc still get written into srcdir).
>
> BTW:
>
> ELCFLAGS=-lbytecomp
>
> is presumably another way to solve your issue, for any version of Emacs
> and automake (once bytecomp is loaded you can redefine functions as you wish).

Thanks for the suggestion, Glenn.
However, I've hit a new snag: subdirs.
I posted details and a smaller stand-alone demonstrator on the
emacs-devel thread: TL;DR this automake test fails regardless:

   make check TESTS='t/lisp-subdir.sh'

Re: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

[Jim Meyering]

On Tue, Nov 28, 2017 at 12:45 PM, Nick Bowler <nbow...@draconx.ca> wrote:
> Hi Jim,
>
> On 2017-11-28 11:21 -0800, Jim Meyering wrote:
>> Date: Thu, 20 Mar 2014 12:31:32 -0700
>> Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)
>>
>> * lib/am/distdir.am (distdir-am): New intermediate target.
>> Interpose this target between $(distdir) and its dependency
>> on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
>> all created before we begin creating $(DISTFILES).
> [...]
>>  NEWS   |  3 +++
>>  lib/am/distdir.am  |  7 --
>>  t/dist-vs-built-sources.sh | 56 
>> ++
>>  t/list-of-tests.mk |  1 +
>>  4 files changed, 65 insertions(+), 2 deletions(-)
>>  create mode 100644 t/dist-vs-built-sources.sh
>
> The Automake manual unequivocally states that BUILT_SOURCES files are
> generated only when running 'make all', 'make check' or 'make install'.
>
> So if they are going to be generated on 'make dist' as well, then the
> manual needs a corresponding update.

Hi Nick,
Thanks for the suggestion, but I do not think it is desired. "make
dist" is already defined as building everything that goes into the
distribution tarball, and that implies it must also build anything
(e.g., from BUILT_SOURCES) that happens to be required to do that.
Perhaps more importantly, this is an implementation detail that feels
like it should not be made part of the contract that the documentation
provides, in case some day automake tightens up "make dist" so it
builds only those BUILT_SOURCES files that are actually required to
build the tarball components.

[PATCH] "make dist" did not depend on $(BUILT_SOURCES)

[Jim Meyering]

I was dismayed to discover this patch I wrote over three years ago.
Today I confirmed that the problem still remains by running these commands:

  git clone git://git.sv.gnu.org/hello.git \
cd hello && ./bootstrap && ./configure && env make dist

It failed like this:

  src/hello.c:27:10: fatal error: configmake.h: No such file or directory
   #include "configmake.h"
^~

Here's the patch I expect to push to master:

From: Jim Meyering <meyer...@fb.com>
Date: Thu, 20 Mar 2014 12:31:32 -0700
Subject: [PATCH] "make dist" did not depend on $(BUILT_SOURCES)

* lib/am/distdir.am (distdir-am): New intermediate target.
Interpose this target between $(distdir) and its dependency
on $(DISTFILES), so that we can ensure $(BUILT_SOURCES) are
all created before we begin creating $(DISTFILES).
* t/dist-vs-built-sources.sh: Test for this.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention it.
Assaf Gordon reported that "make dist" (after ./configure
from a pristine clone of GNU hello) would fail due to the
absence of configmake.h while compiling lib/localcharset.c.
https://lists.gnu.org/r/bug-hello/2014-03/msg00016.html
---
 NEWS   |  3 +++
 lib/am/distdir.am  |  7 --
 t/dist-vs-built-sources.sh | 56 ++
 t/list-of-tests.mk |  1 +
 4 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 t/dist-vs-built-sources.sh

diff --git a/NEWS b/NEWS
index dd057b7b1..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -113,6 +113,9 @@ New in ?.?.?:
   - Installed 'aclocal' m4 macros can now accept installation directories
 containing '@' characters (automake bug#20903)

+  - "./configure && make dist" no longer fails when a distributed file depends
+on one from BUILT_SOURCES.
+
   - When combining AC_LIBOBJ or AC_FUNC_ALLOCA with the
 "--disable-dependency-tracking" configure option in an out of source
 build, the build sub-directory defined by AC_CONFIG_LIBOBJ_DIR is now
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 653966f0e..4b6543591 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -72,10 +72,13 @@ endif %?SUBDIRS%

 .PHONY: distdir
 if %?SUBDIRS%
-AM_RECURSIVE_TARGETS += distdir
+AM_RECURSIVE_TARGETS += distdir distdir-am
 endif %?SUBDIRS%

-distdir: $(DISTFILES)
+distdir: $(BUILT_SOURCES)
+   $(MAKE) $(AM_MAKEFLAGS) distdir-am
+
+distdir-am: $(DISTFILES)
 ##
 ## For Gnits users, this is pretty handy.  Look at 15 lines
 ## in case some explanatory text is desirable.
diff --git a/t/dist-vs-built-sources.sh b/t/dist-vs-built-sources.sh
new file mode 100644
index 0..94f8b600f
--- /dev/null
+++ b/t/dist-vs-built-sources.sh
@@ -0,0 +1,56 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Ensure that "make dist" no longer fails when a distributed file
+# depends on a file from the list of BUILT_SOURCES.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+BUILT_SOURCES = h.h
+h.h:
+   rm -f $@ $@-t
+   printf '%s\n' '#define F "F"' > $@-t
+   mv -f $@-t $@
+CLEANFILES = h.h
+
+EXTRA_DIST = gen
+gen: foo
+   ./foo > $@-t && mv $@-t $@
+
+bin_PROGRAMS = foo
+foo_SOURCES = foo.c
+END
+
+cat > foo.c << 'END'
+#include "h.h"
+int main (void) { printf ("%s\n", F); return 0; }
+END
+chmod a-w foo.c
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE
+
+./configure
+$MAKE dist
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 33e5adc49..fde769971 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -409,6 +409,7 @@ t/dist-missing-m4.sh \
 t/dist-readonly.sh \
 t/dist-repeated.sh \
 t/dist-pr109765.sh \
+t/dist-vs-built-sources.sh \
 t/distcleancheck.sh \
 t/distcom2.sh \
 t/distcom3.sh \
--
2.14.1.729.g59c0ea183

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering <j...@meyering.net> wrote:
> On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote:
>> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote:
>>> Jim Meyering wrote:
>>>
>>>> In May of 2017, support for using the long-deprecated
>>>> byte-compile-dest-file function was removed, and that removal broke
>>>> automake's elisp-compiling rule for any .el file not in the current
>>>> directory.
>>>
>>> In general, Emacs expects .el and .elc to be found in the same
>>> directory. Not adhering to this convention will likely break various
>>> Emacs features. Is this really something automake needs to enable at all?
>>
>> An alternative would be to copy-or-link the .el file into the
>> destination directory. Indeed. That would work without breaking pre-23
>> emacs, so I will adjust my automake patch before pushing it to master.
>
> Hi Glenn,
>
> I've thought about this some more and do not like the idea of
> requiring automake's elisp-compilation rule to make a copy of the
> source file in the destination directory in this slightly contrived
> case. Remember: this arises only in a non-srcdir build. That means
> build artifacts end up being written into the mostly-empty current
> directory hierarchy, which does not have copies of the sources.
> Installation processes will continue to copy both .el and .elc files
> into place.

Here is the updated (NEWS addition) patch that I expect to push to
master tomorrow. Feedback welcome. I will also delete the "micro"
branch I created.
From 7558bddcc9cf5ee14441304c2cfc7cffb566daba Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Wed, 22 Nov 2017 21:07:29 -0800
Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer

In May of 2017, Emacs' support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
We expect the removed functionality to be restored for Emacs-26,
albeit with dissuasive diagnostics warning about the imminent removal
of this functionality.  It may be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
rather than byte-compile-dest-file.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention this problem.
---
 NEWS  |  5 +
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 04a285565..dd057b7b1 100644
--- a/NEWS
+++ b/NEWS
@@ -121,6 +121,11 @@ New in ?.?.?:
   - The time printed by 'mdate-sh' is now using the UTC time zone to support
 the reproducible build effort.  (automake bug#20314)

+  - The elisp byte-compilation rule now uses byte-compile-dest-file-function,
+rather than byte-compile-dest-file, which was obsoleted in 2009. We expect
+that Emacs-26 will continue to support the old function, but will complain
+loudly, and that Emacs-27 will remove support for it altogether.
+
 

 New in 1.15.1:
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..cacbc6feb 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,7 +41,7 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
+   --eval "(setq byte-compile-dest-file-function (lambda (_) \"$@\"))" 
\
--eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
else :; fi

diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote:
> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote:
>> Jim Meyering wrote:
>>
>>> In May of 2017, support for using the long-deprecated
>>> byte-compile-dest-file function was removed, and that removal broke
>>> automake's elisp-compiling rule for any .el file not in the current
>>> directory.
>>
>> In general, Emacs expects .el and .elc to be found in the same
>> directory. Not adhering to this convention will likely break various
>> Emacs features. Is this really something automake needs to enable at all?
>
> An alternative would be to copy-or-link the .el file into the
> destination directory. Indeed. That would work without breaking pre-23
> emacs, so I will adjust my automake patch before pushing it to master.

Hi Glenn,

I've thought about this some more and do not like the idea of
requiring automake's elisp-compilation rule to make a copy of the
source file in the destination directory in this slightly contrived
case. Remember: this arises only in a non-srcdir build. That means
build artifacts end up being written into the mostly-empty current
directory hierarchy, which does not have copies of the sources.
Installation processes will continue to copy both .el and .elc files
into place.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote:
> Jim Meyering wrote:
>
>> In May of 2017, support for using the long-deprecated
>> byte-compile-dest-file function was removed, and that removal broke
>> automake's elisp-compiling rule for any .el file not in the current
>> directory.
>
> In general, Emacs expects .el and .elc to be found in the same
> directory. Not adhering to this convention will likely break various
> Emacs features. Is this really something automake needs to enable at all?

An alternative would be to copy-or-link the .el file into the
destination directory. Indeed. That would work without breaking pre-23
emacs, so I will adjust my automake patch before pushing it to master.

Thanks.

However, please do consider undoing that breaking change before the
next emacs release, so we have a chance to release a fixed version of
automake before you remove the functionality being used in all
existing Makefile.in files.

Re: Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

[Jim Meyering]

On Fri, Nov 24, 2017 at 4:42 AM, Mathieu Lirzin  wrote:
> Mathieu Lirzin  writes:
>
>> Indeed HACKING is not up-to-date, I will fix that.
>
> Here is a patch that should help describing the new branching model more
> accurately.  If you see further improvements or would prefer different
> wording, tell me.

Thanks.
That looks fine.

By the way, I'm waiting to hear from Emacs folks to determine how to
word the NEWS entry for my master-destined elisp-compilation-fix
commit.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin <m...@gnu.org> wrote:
> Hello Jim,
>
> Jim Meyering <j...@meyering.net> writes:
>
>> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote:
>>> I wanted to make a new idutils release, but was blocked because
>>> its "make distcheck" would fail. That was because it distributes
>>> and builds from an elisp file, and automake's elisp-compilation
>>> rule uses a function that was marked obsolete back in 2009.
>>> Upstream Emacs finally removed support for that function in May,
>>> so anyone using emacs built since then will see the same failure
>>> I saw. It also strikes whenever building from a read-only source
>>> directory.
>>>
>>> This change switches the build command to use the "new" way.
>>>
>>> I started discussion on emacs-devel last night:
>>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>>>
>>>
>>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <meyer...@fb.com>
>>> Date: Wed, 22 Nov 2017 21:07:29 -0800
>>> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
>>>
>>> In May of 2017, support for using the long-deprecated
>>> byte-compile-dest-file function was removed, and that removal broke
>>> automake's elisp-compiling rule for any .el file not in the current
>>> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
>>> became the recommended way to adjust the byte-compiler's destination.
>>> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
>>> rather than byte-compile-dest-file.
>>> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
>>> * t/list-of-tests.mk (handwritten_TESTS): Add it.
>>
>> Pushed to the micro branch:
>>
>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39
>
> With the "recent" change in Automake branch naming scheme, 'master'
> seems a better fit for this:
>
>   https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html
>
> Thanks.

Hi Mathieu,
Happy to adjust. Would you prefer that I merge micro into master,
then... or something else? Then delete micro? When I noticed that I'd
created that branch (after reading the description in HACKING), I
figured I'd missed something.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote:
> I wanted to make a new idutils release, but was blocked because
> its "make distcheck" would fail. That was because it distributes
> and builds from an elisp file, and automake's elisp-compilation
> rule uses a function that was marked obsolete back in 2009.
> Upstream Emacs finally removed support for that function in May,
> so anyone using emacs built since then will see the same failure
> I saw. It also strikes whenever building from a read-only source
> directory.
>
> This change switches the build command to use the "new" way.
>
> I started discussion on emacs-devel last night:
> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>
>
> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyer...@fb.com>
> Date: Wed, 22 Nov 2017 21:07:29 -0800
> Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer
>
> In May of 2017, support for using the long-deprecated
> byte-compile-dest-file function was removed, and that removal broke
> automake's elisp-compiling rule for any .el file not in the current
> directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
> became the recommended way to adjust the byte-compiler's destination.
> * lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
> rather than byte-compile-dest-file.
> * t/lisp-readonly-srcdir.sh: New file, to test for the above.
> * t/list-of-tests.mk (handwritten_TESTS): Add it.

Pushed to the micro branch:

https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39

[PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

I wanted to make a new idutils release, but was blocked because
its "make distcheck" would fail. That was because it distributes
and builds from an elisp file, and automake's elisp-compilation
rule uses a function that was marked obsolete back in 2009.
Upstream Emacs finally removed support for that function in May,
so anyone using emacs built since then will see the same failure
I saw. It also strikes whenever building from a read-only source
directory.

This change switches the build command to use the "new" way.

I started discussion on emacs-devel last night:
https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html


>From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Wed, 22 Nov 2017 21:07:29 -0800
Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer

In May of 2017, support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
rather than byte-compile-dest-file.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
---
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..cacbc6feb 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,7 +41,7 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
+   --eval "(setq byte-compile-dest-file-function (lambda (_) \"$@\"))" 
\
--eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
else :; fi

diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Ensure that building elisp from a read-only srcdir works.
+
+required=emacs
+. test-init.sh
+
+cat > Makefile.am << 'EOF'
+lisp_LISP = am-one.el
+EOF
+
+cat >> configure.ac << 'EOF'
+AM_PATH_LISPDIR
+AC_OUTPUT
+EOF
+
+echo > am-one.el
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+mkdir sub
+chmod a=rx .
+
+cd sub
+../configure
+$MAKE
+
+test -f am-one.elc
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d234aef48..3dab63d32 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -656,6 +656,7 @@ t/lisp5.sh \
 t/lisp6.sh \
 t/lisp7.sh \
 t/lisp8.sh \
+t/lisp-readonly-srcdir.sh \
 t/lisp-loadpath.sh \
 t/lisp-subdir.sh \
 t/lisp-subdir2.sh \
--
2.14.1.729.g59c0ea183

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

[Jim Meyering]

On Mon, Aug 29, 2016 at 11:05 PM, Thomas Martitz  wrote:
> This option is intended to be used in conjunction with subdir-objects and
> Automake-time substitutions for included makefile fragments (%C%, %D%).
> Enabling the option shortens the file name of object files such that the
> prefix
> derived (after canonicalization) from the path is not included.
>
> Enabling the option is basically equivalent to setting foo_SHORTNAME =
> foo. However, it also works flawlessly if a Makefile fragment is
> conditionally included. Note that actually setting foo_SHORTNAME
> still overrides the object name, regardless of this option. This can improve
> the modularity of Automake-using projects.
>
> Example:
> without object-shortname
>   sub/Makefile.am:
>   bin_PROGRAMS += %D%/foo
>   %C%_foo_CFLAGS = $(AM_CFLAGS) -g
>
> results in objects:
>   sub/sub_foo-foo.o
>
> with object-shortname the object file name is:
>   sub/foo-foo.o
>
> And it allows the following in $(top_srcdir)/Makefile.am (not possible with
> foo_SHORTNAME=foo)
>
>   if ENABLE_SUB
>   include sub/Makefile.am
>   endif

Hi Thomas,

Thanks for the addition.

I've only spent a few minutes reading discussion about this patch and
even less looking at the actual code, but so far, I have seen no
addition to the test suite. I suggest you copy an existing test as a
starting point, add something like the above in its Makefile.am
section, and then ensure that the new artifacts appear in the
generated Makefile.in.

Automake is at a point in its development for which we should ensure
(whenever possible) that any nontrivial change includes a test suite
addition to exercise the new behavior. If it's a bug fix, the new
test(s) should fail before the fix and pass once it is applied. For a
feature addition like this, it is often similar: the new test should
exercise/demonstrate the new code, and should usually fail without the
patch.

Jim

FYI: update copyright dates for 2017

[Jim Meyering]

FYI, I've just pushed a commit to update copyright dates:

  maint: update copyright dates for 2017

  * all files: Run this command, using update-copyright from gnulib:
UPDATE_COPYRIGHT_FORCE=1 \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79 \
 update-copyright $(git ls-files)

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

[Jim Meyering]

On Thu, Sep 8, 2016 at 7:20 PM, Paul Eggert <egg...@cs.ucla.edu> wrote:
> 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.

Thanks, Paul.

bug#23661: [PATCH] compile: remove .Tpo file upon failure

[Jim Meyering]

On Mon, May 30, 2016 at 9:08 PM, Jim Meyering <j...@meyering.net> wrote:
> I was annoyed not to be able to use automake's latest-from-master
> while preparing for a diffutils release: "make distcheck" would fail
> with a single left-over .Tpo file under gnulib-tests.
>
> Here is the patch that solved the problem for me.
> Comments welcome. I expect to push to master in a day or two.

I've pushed that to master.

bug#23661: [PATCH] compile: remove .Tpo file upon failure

[Jim Meyering]

I was annoyed not to be able to use automake's latest-from-master
while preparing for a diffutils release: "make distcheck" would fail
with a single left-over .Tpo file under gnulib-tests.

Here is the patch that solved the problem for me.
Comments welcome. I expect to push to master in a day or two.
From c6dff7e2cac2e8dc5407c77998ef0ac2ba538891 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Mon, 30 May 2016 17:07:52 -0700
Subject: [PATCH] compile: remove .Tpo file upon failure

When generating a .deps/base.Po file, we
first write to a temporary .Tpo file, so the final creation can be atomic,
via mv's rename.  However, when generation of the .Tpo fails, we stop
the process and do not remove that temporary file.  And nothing else
ever deletes it, either.  Hence, in the unusual case in which one
expects a compilation to fail during a successful build (gnulib's
test-verify.sh does precisely this), a .deps/test-verify.Tpo file
would be left behind, and that would in turn cause a "make distcheck"
failure because that file would exist in one build+distclean
hierarchy but not in the distribution tarball.
* lib/am/depend2.am: Ensure that the temporary file is removed
upon failure.
* t/distcheck-Tpo.sh: New file.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
---
 lib/am/depend2.am  | 10 ++
 t/distcheck-Tpo.sh | 58 ++
 t/list-of-tests.mk |  1 +
 3 files changed, 65 insertions(+), 4 deletions(-)
 create mode 100644 t/distcheck-Tpo.sh

diff --git a/lib/am/depend2.am b/lib/am/depend2.am
index 87f62a8..d1478b9 100644
--- a/lib/am/depend2.am
+++ b/lib/am/depend2.am
@@ -42,8 +42,9 @@ if %?NONLIBTOOL%
 ?!GENERIC?%OBJ%: %SOURCE%
 if %FASTDEP%
 	%VERBOSE%$(am__set_depbase) && \
-	%COMPILE% -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ %SOURCEFLAG% %XSOURCE% && \
-	$(am__mv) $$depbase.Tpo $$depbase.Po
+	%COMPILE% -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ %SOURCEFLAG% %XSOURCE%; \
+	if test $$? = 0; then $(am__mv) $$depbase.Tpo $$depbase.Po; \
+	  else rm -f $$depbase.Tpo; false; fi
 else !%FASTDEP%
 if %AMDEP%
 	%VERBOSE%source='%SOURCE%' object='$@' libtool=no @AMDEPBACKSLASH@
@@ -56,8 +57,9 @@ endif !%FASTDEP%
 ?!GENERIC?%OBJOBJ%: %SOURCE%
 if %FASTDEP%
 	%VERBOSE%$(am__set_depbase) && \
-	%COMPILE% -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ %SOURCEFLAG% $$($(CYGPATH_W) %XSOURCE%) && \
-	$(am__mv) $$depbase.Tpo $$depbase.Po
+	%COMPILE% -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ %SOURCEFLAG% $$($(CYGPATH_W) %XSOURCE%); \
+	if test $$? = 0; then $(am__mv) $$depbase.Tpo $$depbase.Po; \
+	  else rm -f $$depbase.Tpo; false; fi
 else !%FASTDEP%
 if %AMDEP%
 	%VERBOSE%source='%SOURCE%' object='$@' libtool=no @AMDEPBACKSLASH@
diff --git a/t/distcheck-Tpo.sh b/t/distcheck-Tpo.sh
new file mode 100644
index 000..9d7900c
--- /dev/null
+++ b/t/distcheck-Tpo.sh
@@ -0,0 +1,58 @@
+#! /bin/sh
+# Copyright (C) 2016 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Ensure that the 'make distcheck'-run distcleancheck does not fail
+# due to a leftover .deps/base.Tpo file when part of a successful build
+# involves a failed attempt to create a .deps/base.Po file.
+
+. test-init.sh
+
+cat >> configure.ac < foo.c <<\END
+#ifndef FAIL
+int main() { return 0; }
+#else
+int x[no_such];
+#endif
+END
+
+cat > Makefile.am <<\END
+TESTS = foo bar.test
+check_PROGRAMS = foo
+EXTRA_DIST= bar.test foo.c
+END
+
+cat > bar.test <

bug#23491: [Automake] Proposed upgrade of the home page

[Jim Meyering]

On Mon, May 9, 2016 at 1:34 AM, Thérèse Godefroy  wrote:
> Hello,
>
> I am a member of the gnu.org French translation team [0], and also try
> to update obsolete features in web pages to make future style
> improvement easier. automake.html [1] has the old kind of translation
> list at the bottom of the page; I propose to upgrade it to boilerplate
> 1.79 [2]. This would give the opportunity of fixing a few XHTML errors
> (see the attached diff).
>
> If you agree with the proposed changes but don't have time to commit
> them to CVS, I will be glad to do it (provided the repository isn't
> locked), with any further modifications you specify.
>
> Best regards,
> Therese
>
>
> [0] https://www.gnu.org/server/standards/README.translations.html#teams
> [1] https://www.gnu.org/software/automake/automake.html
> [2]
> http://web.cvs.savannah.gnu.org/viewvc/*checkout*/www/server/standards/boilerplate.html?root=www=text%2Fplain


Hi Thérèse, thank you for tending so many of our web pages.
You are welcome to make those changes.

Merci encore,

Jim

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

[Jim Meyering]

On Tue, Feb 16, 2016 at 9:34 AM, Nelson H. F. Beebe <be...@math.utah.edu> wrote:
...
Thank you for all of the feedback.
I agree that many of the failures are due to inadequate library
support, and we should eventually improve the tests to detect
the inferior interfaces and diagnose them as such. However,
that is not on my short list, for now.

> In addition, compilation on MacOS X 10.10 (Yosemite) and 10.11 (El
> Capitan) produces these warnings from clang masquerading as gcc:
>
> make[3]: Entering directory 
> '/private/var/tmp/build/bare/grep-2.23/lib'
> Makefile:1684: target '.deps/alloca.Po' given more than once in the 
> same rule
>   CC   argmatch.o

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.
From 7a5fb319e557a94b64785d4312ceda197e317248 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
Date: Thu, 18 Feb 2016 09:19:44 -0800
Subject: [PATCH] do not emit rule with two .deps/alloca.Po dependents

On a system using our replacement alloca, make would emit
this warning:
  target '.deps/alloca.Po' given more than once in the same rule
That arose because automake would emit a rule depending on both
./.deps/alloca.Po and .deps/alloca.Po. Normally, duplicate
dependents are avoided by virtue of their names being keys in
the %dep_files hash, but in this case, that particular file
was specified in two different ways.
* bin/automake.in (handle_ALLOCA): When the $dir prefix is empty,
make it './', to ensure that when we add ./.deps/alloca.Po
it is deduped.
---
 bin/automake.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bin/automake.in b/bin/automake.in
index c1d1a8a..7508bc2 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2208,6 +2208,7 @@ sub handle_ALLOCA
   $lt ||= '';
   my $dir = handle_LIBOBJS_or_ALLOCA "${lt}ALLOCA";

+  $dir eq '' and $dir = './';
   $var->requires_variables ("\@${lt}ALLOCA\@ used", $lt . 'ALLOCA');
   $dep_files{$dir . '$(DEPDIR)/alloca.P' . $myobjext} = 1;
   require_libsource_with_macro ($cond, $var, FOREIGN, 'alloca.c');
-- 
2.6.4

[PATCH] tests: depcomp2: avoid spurious failure on OS/X

[Jim Meyering]

I expect to push this trivial patch to master by Monday.
Holler if you'd rather it go elsewhere.
From 5ac6a241b117f372808b9d2a6ac78ca9af42dfaf Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@fb.com
Date: Thu, 20 Mar 2014 13:44:48 -0700
Subject: [PATCH] tests: depcomp2: avoid spurious failure on OS/X

* t/depcomp2.sh: Relax stderr-filtering regexp so that it also
works when the file name in the diagnostic is quoted, e.g.,
rm: cannot remove 'conftest.dSYM': Is a directory
---
 t/depcomp2.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/depcomp2.sh b/t/depcomp2.sh
index 3eba12d..3baaebf 100644
--- a/t/depcomp2.sh
+++ b/t/depcomp2.sh
@@ -47,7 +47,7 @@ $AUTOCONF
 cat stderr 2
 # Ignore warning messages sometimes seen on Mac OS X; they are
 # not automake's fault anyway, but either autoconf's or Mac's.
-sed '/rm:.* conftest\.dSYM/d' stderr stderr2
+sed '/rm:.*conftest\.dSYM/d' stderr stderr2
 test -s stderr2  { cat stderr2; exit 1; }

 :
-- 
1.9.2.459.g68773ac

Re: reinstate AM_PROG_MKDIR_P

[Jim Meyering]

Stefano Lattarini wrote:
 On 10/25/2012 07:32 PM, Jim Meyering wrote:
 You wrote:
 OK, if someone sends a patch reverting the AM_PROG_MKDIR_P removal (with a
 rationale in the commit message), I'll take it.  But AM_PROG_MKDIR_P will
 be dropped in 1.14, without further ifs or buts.

 Hi Stefano,

 Here's the promised patch.
 This is relative to master and make check still passes.

 Thanks.  The patch will be OK to go after one nit (see below) is
 resolved.

 But please note that I'm going to remove AM_PROG_MKDIR_P for good in
 Automake 1.14, independently of what gettext does; so you might want
 to put some pressure on that project to accept my pending patch that
 makes it use AC_PROG_MKDIR_P instead of AM_PROG_MKDIR_P:

   http://lists.gnu.org/archive/html/bug-gettext/2012-10/msg1.html

I suggest that you request commit privileges.
If granted, you'll be able to apply it yourself.

...
 Subject: [PATCH] reinstate AM_PROG_MKDIR_P

 Feel free to ignore this, but: what about using the compat prefix for
 the summary line, and giving few more details?  As in

 compat: reinstate AM_PROG_MKDIR_P, for gettext

No trouble.  Done.

...
 * doc/automake.texi (Obsolete Macros): Restore deleted section.

 Could you please restore only the entry for AM_PROG_MKDIR_P, rather
 than the entire section?  Thanks.

Done, too.

 ACK with that addressed.

Pushed.  Thanks for the review.

reinstate AM_PROG_MKDIR_P

[Jim Meyering]

You wrote:
 OK, if someone sends a patch reverting the AM_PROG_MKDIR_P removal (with a
 rationale in the commit message), I'll take it.  But AM_PROG_MKDIR_P will
 be dropped in 1.14, without further ifs or buts.

Hi Stefano,

Here's the promised patch.
This is relative to master and make check still passes.

I have spent too little time investigating the merge conflicts,
so odds are good that you'll find more than nits to pick.


From 0593ddfd6f6a2ed58aaa1aa7e0b361d4a5108924 Mon Sep 17 00:00:00 2001
From: Jim Meyering j...@meyering.net
Date: Mon, 22 Oct 2012 16:14:49 +0200
Subject: [PATCH] reinstate AM_PROG_MKDIR_P

Do not remove AM_PROG_MKDIR_P just yet.

gettext (latest from git) still AC_REQUIRE's AM_PROG_MKDIR_P via its
intl.m4 and po.m4 files, which are pulled into *many* projects.

When I try to build one of those projects (coreutils) using the latest
from automake.git/master, I see this failure:

$ aclocal -I m4
configure.ac:477: warning: AM_PROG_MKDIR_P is m4_require'd \
  but not m4_defun'd
m4/po.m4:23: AM_PO_SUBDIRS is expanded from...
m4/gettext.m4:57: AM_GNU_GETTEXT is expanded from...
configure.ac:477: the top level

That is because AM_PROG_MKDIR_P was removed (via commit
v1.12-20-g8a1c64f) in preparation for the next release of automake.

* NEWS: Remove the paragraph that announced the removal of
AM_PROG_MKDIR_P.
* Makefile.am (dist_automake_ac_DATA): Add m4/mkdirp.m4.
* m4/mkdirp.m4: Re-add file.
* t/mkdirp-deprecation.sh: Likewise.
* t/list-of-tests.mk: Add it.
* automake.in: Restore removed code, and adjust comments, s/1.13/1.14/
to reflect new plan for removal.
* doc/automake.texi (Obsolete Macros): Restore deleted section.
---
 Makefile.am |  1 +
 automake.in |  9 +++
 doc/automake.texi   | 62 +
 m4/mkdirp.m4| 31 +
 t/gettext-macros.sh | 13 +++
 t/list-of-tests.mk  |  1 +
 t/mkdirp-deprecation.sh | 48 ++
 7 files changed, 160 insertions(+), 5 deletions(-)
 create mode 100644 m4/mkdirp.m4
 create mode 100755 t/mkdirp-deprecation.sh

diff --git a/Makefile.am b/Makefile.am
index e629787..0e959da 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -276,6 +276,7 @@ dist_automake_ac_DATA = \
   m4/make.m4 \
   m4/minuso.m4 \
   m4/missing.m4 \
+  m4/mkdirp.m4 \
   m4/options.m4 \
   m4/protos.m4 \
   m4/python.m4 \
diff --git a/automake.in b/automake.in
index 9c0c8b9..32389f4 100644
--- a/automake.in
+++ b/automake.in
@@ -5128,6 +5128,7 @@ sub scan_autoconf_traces ($)
AC_REQUIRE_AUX_FILE = 1,
AC_SUBST_TRACE = 1,
AM_AUTOMAKE_VERSION = 1,
+AM_PROG_MKDIR_P = 0, # FIXME: to be removed in 1.14
AM_CONDITIONAL = 2,
_AM_EXTRA_RECURSIVE_TARGETS = 1,
AM_GNU_GETTEXT = 0,
@@ -5283,6 +5284,14 @@ sub scan_autoconf_traces ($)

  $seen_automake_version = 1;
}
+  elsif ($macro eq 'AM_PROG_MKDIR_P') # FIXME: to be removed in 1.14
+   {
+ msg 'obsolete', $where, 'EOF';
+The 'AM_PROG_MKDIR_P' macro is deprecated, and will soon be removed.
+You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
+and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
+EOF
+   }
   elsif ($macro eq 'AM_CONDITIONAL')
{
  $configure_cond{$args[1]} = $where;
diff --git a/doc/automake.texi b/doc/automake.texi
index 7058545..aa6f67d 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3880,6 +3880,7 @@ Macros

 @menu
 * Public Macros::   Macros that you can use.
+* Obsolete Macros:: Macros that will soon be removed.
 * Private Macros::  Macros that you should not use.
 @end menu

@@ -4046,6 +4047,67 @@ Public Macros
 @end table


+@node Obsolete Macros
+@subsection Obsolete Macros
+@cindex obsolete macros
+@cindex autoupdate
+
+Although using some of the following macros was required in past
+releases, you should not use any of them in new code.  @emph{All
+these macros will be removed in the next major Automake version};
+if you are still using them, running @command{autoupdate} should
+adjust your @file{configure.ac} automatically (@pxref{autoupdate
+Invocation, , Using @command{autoupdate} to Modernize
+@file{configure.ac}, autoconf, The Autoconf Manual}).
+@emph{Do it NOW!}
+
+@table @code
+
+@item AM_CONFIG_HEADER
+@acindex AM_CONFIG_HEADER
+Automake will generate rules to automatically regenerate the config
+header.  This obsolete macro is a synonym of @code{AC_CONFIG_HEADERS}
+today (@pxref{Optional}).
+
+@item AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
+@acindex AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
+If the use of @code{TIOCGWINSZ} requires @file{sys/ioctl.h}, then
+define @code{GWINSZ_IN_SYS_IOCTL}.  Otherwise @code{TIOCGWINSZ} can be
+found in @file{termios.h}.  This macro is obsolete, you should
+use Autoconf's

[PATCH] maint: typo fixes s/lies into/lies in/

[Jim Meyering]

Pushed to maint as obvious/trivial:

From dcff988359f0dba5d133bbacde8fcb983108ccbf Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 23 Sep 2012 18:22:30 +0200
Subject: [PATCH] maint: typo fixes s/lies into/lies in/

---
 automake.in | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/automake.in b/automake.in
index 8c8b127..0983def 100644
--- a/automake.in
+++ b/automake.in
@@ -2544,8 +2544,8 @@ sub handle_programs
   my($xlink, $vlink) = define_per_target_linker_variable ($linker, 
$xname);
   $vlink = verbose_flag ($vlink || 'GEN');

-  # If the resulting program lies into a subdirectory,
-  # make sure this directory will exist.
+  # If the resulting program lies in a subdirectory,
+  # ensure that the directory exists before we need it.
   my $dirstamp = require_build_directory_maybe ($one_file);

   $libtool_clean_directories{dirname ($one_file)} = 1;
@@ -2655,7 +2655,7 @@ sub handle_libraries
   handle_source_transform ($xlib, $onelib, $obj, $where,
NONLIBTOOL = 1, LIBTOOL = 0);

-  # If the resulting library lies into a subdirectory,
+  # If the resulting library lies in a subdirectory,
   # make sure this directory will exist.
   my $dirstamp = require_build_directory_maybe ($onelib);
   my $verbose = verbose_flag ('AR');
@@ -2899,7 +2899,7 @@ sub handle_ltlibraries
}
}

-  # If the resulting library lies into a subdirectory,
+  # If the resulting library lies in a subdirectory,
   # make sure this directory will exist.
   my $dirstamp = require_build_directory_maybe ($onelib);

@@ -3129,7 +3129,7 @@ sub output_texinfo_build_rules ($$$@)
   # extension).
   my $generic_info = ($generic  $dsfx) ? 1 : 0;

-  # If the resulting file lie into a subdirectory,
+  # If the resulting file lies in a subdirectory,
   # make sure this directory will exist.
   my $dirstamp = require_build_directory_maybe ($dest);

--
1.7.12.1.382.gb0576a6

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

Stefano Lattarini wrote:

 On 09/12/2012 09:20 PM, Jim Meyering wrote:
 Stefano Lattarini wrote:
 On 09/12/2012 06:04 PM, Jim Meyering wrote:
 I see that gettext (latest from git) still AC_REQUIRE's
 AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which
 are pulled into *many* projects.

 I know.  I sent a patch several months ago to gettext to fix that issue:

   http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html

 and other peoples have reported the problem as well:

   http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html

 but no answer/feedback has come.

 If gettext doesn't fix the issue, projects using it will have to put a
 workaround in place themselves, like adding an AM_PROG_MKDIR_P definition
 (simply as an alias to AC_PROG_MKDIR_P) in a local '.m4' file.  Sorry.

 Even if gettext fixes it today, it will take months, if not years
 for the new version to reach developers.

 That's why I sent the patch to gettext months ago, sigh :-(

 Are you sure you want to force every automake-and-gettext-using project
 to adapt to what looks like a whim?

 Please reconsider.

 OK, if someone sends a patch reverting the AM_PROG_MKDIR_P removal (with a
 rationale in the commit message), I'll take it.  But AM_PROG_MKDIR_P will
 be dropped in 1.14, without further ifs or buts.

Thank you.  I will make time to prepare the patch.

[PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

[Jim Meyering]

* t/gettext-macros.sh: Fix typo in name of macro emitted into
mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/
---
 t/gettext-macros.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/gettext-macros.sh b/t/gettext-macros.sh
index 1d94dad..f548d1a 100755
--- a/t/gettext-macros.sh
+++ b/t/gettext-macros.sh
@@ -80,7 +80,7 @@ echo export ACLOCAL_PATH  get.sh

 # Even recent versions of gettext used the now-obsolete 'AM_PROG_MKDIR_P'
 # m4 macro.  So we need the following to avoid spurious errors.
-echo 'AC_DEFUN([AM_MKDIR_P], [AC_MKDIR_P([$@])])'  m4/mk-dirp.m4
+echo 'AC_DEFUN([AM_PROG_MKDIR_P], [AS_MKDIR_P([$@])])'  m4/mk-dirp.m4

 . ./get.sh

--
1.7.12.363.g53284de

Re: [PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

[Jim Meyering]

Stefano Lattarini wrote:
 Hi Jim, thanks for the patch.

 On 09/12/2012 05:53 PM, Jim Meyering wrote:

 * t/gettext-macros.sh: Fix typo in name of macro emitted into
 mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

 Yikes, how have I been missing that ?!?

 Maybe, to help me (and future readers) to understand how this blunder can have
 survived so long, you could elaborate, in the commit message, about how you've
 been bitten by it, or how you've come across it ...

I found it by inspection while trying to figure out what was
causing aclocal to gripe about the to-be-obsoleted (and now missing
for me) AM_PROG_MKDIR_P macro.

  t/gettext-macros.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/t/gettext-macros.sh b/t/gettext-macros.sh
 index 1d94dad..f548d1a 100755
 --- a/t/gettext-macros.sh
 +++ b/t/gettext-macros.sh
 @@ -80,7 +80,7 @@ echo export ACLOCAL_PATH  get.sh

  # Even recent versions of gettext used the now-obsolete 'AM_PROG_MKDIR_P'
  # m4 macro.  So we need the following to avoid spurious errors.
 -echo 'AC_DEFUN([AM_MKDIR_P], [AC_MKDIR_P([$@])])'  m4/mk-dirp.m4
 +echo 'AC_DEFUN([AM_PROG_MKDIR_P], [AS_MKDIR_P([$@])])'  m4/mk-dirp.m4

 I believe you should also do the change 's/AS_MKDIR_P/AC_PROG_MKDIR_P/'.

Sounds good, but I confess I haven't really investigated,
so don't know the effects of the fixes.

I presume you'd like this to be committed on maint?

From 335cea6d5e62d011f9fe1f470d336d85599a5ef5 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 12 Sep 2012 17:31:24 +0200
Subject: [PATCH] fix typos in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

* t/gettext-macros.sh: Fix typo in name of macro emitted into
mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/,
and as Stefano Lattarini noted, also fix this typo:
s/AS_MKDIR_P/AC_PROG_MKDIR_P/.
---
 t/gettext-macros.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/gettext-macros.sh b/t/gettext-macros.sh
index 1d94dad..cbc5565 100755
--- a/t/gettext-macros.sh
+++ b/t/gettext-macros.sh
@@ -80,7 +80,7 @@ echo export ACLOCAL_PATH  get.sh

 # Even recent versions of gettext used the now-obsolete 'AM_PROG_MKDIR_P'
 # m4 macro.  So we need the following to avoid spurious errors.
-echo 'AC_DEFUN([AM_MKDIR_P], [AC_MKDIR_P([$@])])'  m4/mk-dirp.m4
+echo 'AC_DEFUN([AM_PROG_MKDIR_P], [AC_PROG_MKDIR_P([$@])])'  m4/mk-dirp.m4

 . ./get.sh

--
1.7.12.363.g53284de

Re: [PATCH] fix typo in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

[Jim Meyering]

Stefano Lattarini wrote:
 On 09/12/2012 09:38 PM, Jim Meyering wrote:

 I presume you'd like this to be committed on maint?

 OK thanks, with just one nit ...

Pushed to master.  The offending code is not on maint.

 From 335cea6d5e62d011f9fe1f470d336d85599a5ef5 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@redhat.com
 Date: Wed, 12 Sep 2012 17:31:24 +0200
 Subject: [PATCH] fix typos in mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/

 * t/gettext-macros.sh: Fix typo in name of macro emitted into
 mk-dirp.m4: s/AM_MKDIR_P/AM_PROG_MKDIR_P/,
 and as Stefano Lattarini noted, also fix this typo:
 s/AS_MKDIR_P/AC_PROG_MKDIR_P/.

 ... here it should be 'AC_MKDIR_P', not 'AS_MKDIR_P'.

Done.

libvirt build failure w/GNU make and automake.git (automake regression?)

[Jim Meyering]

When I run ./autogen.sh  make, I see this:
(this arose because I had the latest automake.git/master tools --
 commit c1b83e1af60b866cf5cdeebf77d0275019bad8b2 from today --
 early in my path)

Generated 3 wrapper functions
  CC   libvirtmod_la-libvirt-override.lo
  CC   libvirtmod_la-typewrappers.lo
  CC   libvirtmod_la-libvirt.lo
  CC   libvirtmod_qemu_la-libvirt-qemu-override.lo
  CC   libvirtmod_qemu_la-typewrappers.lo
  CC   libvirtmod_qemu_la-libvirt-qemu.lo
  CCLD libvirtmod_qemu.la
  CCLD libvirtmod.la
make[3]: Leaving directory `/h/j/w/co/libvirt/python'
Making all in tests
make[3]: Entering directory `/h/j/w/co/libvirt/python/tests'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/h/j/w/co/libvirt/python/tests'
make[2]: Leaving directory `/h/j/w/co/libvirt/python'
Making all in tests
make[2]: Entering directory `/h/j/w/co/libvirt/tests'
Makefile:4355: *** Malformed target-specific variable definition.  Stop.
make[2]: Leaving directory `/h/j/w/co/libvirt/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/h/j/w/co/libvirt'
make: *** [all] Error 2

That is because of this automake-generated rule:

undefine.log: undefine
@p='undefine'; \
b='undefine'; \
$(am__check_pre) $(LOG_DRIVER) --test-name $$f \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) 
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
$$tst $(AM_TESTS_FD_REDIRECT)

The trouble is that undefine is an operator in GNU make.
Here's that part of GNU make's documentation:

6.9 Undefining Variables


If you want to clear a variable, setting its value to empty is usually
sufficient. Expanding such a variable will yield the same result (empty
string) regardless of whether it was set or not. However, if you are
using the `flavor' (*note Flavor Function::) and `origin' (*note Origin
Function::) functions, there is a difference between a variable that
was never set and a variable with an empty value.  In such situations
you may want to use the `undefine' directive to make a variable appear
as if it was never set. For example:

 foo := foo
 bar = bar

 undefine foo
 undefine bar

 $(info $(origin foo))
 $(info $(flavor bar))

   This example will print undefined for both variables.

   If you want to undefine a command-line variable definition, you can
use the `override' directive together with `undefine', similar to how
this is done for variable definitions:

 override undefine CFLAGS

The most pragmatic work-around is to rename the undefine test script.
However, Stephano, as automake maintainer, I think you will want to
fix automake not to prohibit the use of such test names.

AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

I see that gettext (latest from git) still AC_REQUIRE's
AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which
are pulled into *many* projects.

When I try to build one of those projects (coreutils) using the latest
from automake.git/master, I see this failure:

$ aclocal -I m4
configure.ac:477: warning: AM_PROG_MKDIR_P is m4_require'd but not 
m4_defun'd
m4/po.m4:23: AM_PO_SUBDIRS is expanded from...
m4/gettext.m4:57: AM_GNU_GETTEXT is expanded from...
configure.ac:477: the top level

That is because AM_PROG_MKDIR_P is marked to become obsolete
in the next release of automake.

I would have noticed sooner, but a few months ago, I worked
around this by installing a private fix in the --prefix=/p hierarchy
where I install personal copies of tools like this, then forgot to
report it.  Today I built using the latest automake on a new system
(without that manual patch) and re-diagnosed the problem.

$ cat /p/share/aclocal-1.12a/mkdirp.m4
##  -*- Autoconf -*-
# Copyright (C) 2003-2012 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.

# serial 2

# AM_PROG_MKDIR_P
# ---
# Check for 'mkdir -p'.
AC_DEFUN([AM_PROG_MKDIR_P],
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
dnl Automake 1.8 to 1.9.6 used to define mkdir_p.  We now use MKDIR_P,
dnl while keeping a definition of mkdir_p for backward compatibility.
dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
dnl Makefile.ins that do not define MKDIR_P, so we do our own
dnl adjustment using top_builddir (which is defined more often than
dnl MKDIR_P).
AC_SUBST([mkdir_p], [$MKDIR_P])dnl
case $mkdir_p in
  [[\\/$]]* | ?:[[\\/]]*) ;;
  */*) mkdir_p=\$(top_builddir)/$mkdir_p ;;
esac
])

Re: AM_PROG_MKDIR_P: too soon to obsolete this macro?

[Jim Meyering]

Stefano Lattarini wrote:
 On 09/12/2012 06:04 PM, Jim Meyering wrote:
 I see that gettext (latest from git) still AC_REQUIRE's
 AM_PROG_MKDIR_P from its intl.m4 and po.m4 files, which
 are pulled into *many* projects.

 I know.  I sent a patch several months ago to gettext to fix that issue:

   http://lists.gnu.org/archive/html/bug-gettext/2012-04/msg00018.html

 and other peoples have reported the problem as well:

   http://lists.gnu.org/archive/html/bug-gettext/2012-06/msg00012.html

 but no answer/feedback has come.

 If gettext doesn't fix the issue, projects using it will have to put a
 workaround in place themselves, like adding an AM_PROG_MKDIR_P definition
 (simply as an alias to AC_PROG_MKDIR_P) in a local '.m4' file.  Sorry.

Even if gettext fixes it today, it will take months, if not years
for the new version to reach developers.  Are you sure you want to
force every automake-and-gettext-using project to adapt to what looks
like a whim?

Please reconsider.

latest automake makes emacs bootstrap fail

[Jim Meyering]

Just a heads up:

In the very latest automake (from git), $MISSING is now invoked
with the --is-lightweight option.

That new usage causes emacs' bootstrap (also from git) to fail because
its missing script does not yet know about the --is-lightweight option.

In my case, I've simply copied automake's newer missing script
into my cloned emacs build tree, and with that the emacs bootstrap
now succeeds.

Jim

bug#12320: bison 2.6.2 contains stale info files

[Jim Meyering]

Akim Demaille wrote:
...
 So, Karl, Jim, and others, would you accept that gendocs.sh
 stopped generating a compressed tarball of split info files,
 but would rather ship a compressed --no-split file?

Sounds fine to me, but gendocs.sh is Karl's baby ;-)

Re: parallel make check output lines are lost!?!

[Jim Meyering]

Stefano Lattarini wrote:
 Hi Jim.

 On 08/01/2012 04:52 PM, Jim Meyering wrote:
 I ran coreutils make check tests 60 times (on Fedora 17, x86_64),
 recording the results of each run like this:

 for i in $(seq 100); do make -j25 check

 So, parallel make ...

 -C tests VERBOSE=yes \
   RUN_EXPENSIVE_TESTS=no  makerr-$i

 ... and output redirection.  Bad combination; take a look at:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11413#8

 So, if this is to be considered a bug, it is a make bug, not an
 Automake one IMHO.  To verify that this is the case you might want
 to re-try your 100 runs above with this slight change:

for i in $(seq 100); do
   +   :  makerr-$i
   make -j25 check -C tests VERBOSE=yes \
 RUN_EXPENSIVE_TESTS=no  makerr-$i \
t=. || t=X
   printf $t
done

 and verify that in this case all the 'makerr-*' files are indeed equal.

Hi Stefano,

Thanks for the pointer.  I knew that rang a bell.
For the record, to avoid the problem one must append to the existing log file:

 for i in $(seq 100); do
+   :  makerr-$i
make -j25 check -C tests VERBOSE=yes \
- RUN_EXPENSIVE_TESTS=no  makerr-$i \
+ RUN_EXPENSIVE_TESTS=no  makerr-$i \
 t=. || t=X
printf $t
 done