bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

Hi Erik,

* color-tests2.sh and color-tests2-w.sh fail -- logs attached.

Is this with the old make 3.81 from the system, or the new make you
compiled? What is in the "stdout" file in t/color-tests2.dir/stdout?
And, are these the only two tests that fail in the entire suite?

What I see in the log you sent is that color-tests2.log correctly runs 
  make  pass fail skip xpass xfail error
But then the test output only shows the PASS line:
..
make  check-TESTS
^[[0;32mPASS^[[m: pass
+ test_color
..
I believe that is doing "cat stdout", so everything else is missing,
even the Automake "Testsuite summary" footer.

I don't know why. It's as if the output from the parallel running of
make check overwrote itself, or maybe never ran. But this is not a
problem that's ever been reported before (and doesn't happen for me),
and I haven't knowingly changed anything here.

Thus I somewhat suspect this is some problem of make, and/or expect,
and/or something else. If it's something we can detect, we could skip
the test if we can't fix it. Help?

On my system, I see (I'll attach the whole log):
..
make  check-TESTS
make[1]: Entering directory '/u/karl/gnu/src/akarl/t/color-tests2.dir'
make[2]: Entering directory '/u/karl/gnu/src/akarl/t/color-tests2.dir'
^[[0;32mPASS^[[m: pass
^[[0;31mFAIL^[[m: fail
^[[1;34mSKIP^[[m: skip
^[[0;31mXPASS^[[m: xpass
^[[1;32mXFAIL^[[m: xfail
^[[0;35mERROR^[[m: error
^[[0;31m^[[m
^[[0;31mTestsuite summary for color-tests2 1.0^[[m
..
+ test_color
..

(For the sake of this mail, I've removed ^M characters and replaced true
^[ ESC character with ASCII ^[.)

BTW, color-tests2-w is just a wrapper of color-tests2 to test VPATH, so
if we can solve color-tests2, its problems should go away too.

Thanks,
Karl



color-tests2.log
Description: Binary data

bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

* fine on the tests that failed previously because of macOS default
  make having only second resolution

Great! Thanks much for the instant testing.

* color-tests2.sh and color-tests2-w.sh fail -- logs attached.

I had tweaked some of the color stuff, so I must have messed up
somewhere. Will check. -k

bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

Hi Erik and all - I (finally) made the change below to have automake
test for a make that doesn't support subsecond mtimes even when the rest
of the system is ok, as you noted happens with the make-3.81 shipped by
macOS.

I installed make-3.8.1 on my Rocky 9 system, but it did not cause the
lossage. So I'm not sure if there's an error in my test (wouldn't
surprise me) or if it's something about the mac system specifically.

As far as I could tell, the new code does succeed on Rocky 9. So I hope
it also succeeds on other current systems where the whole
subsecond-mtime thing is intended.

Erik, can you either apply this patch (and remake and run the tests), or
get the current automake dev sources and try it?

If anyone (Zack, Bogdan, Jim, ...) else could look at, and/or try, the
new code and see if any problems show up, that would be great.

I hope this works and we can start pushing towards the release. --thanks, karl.

--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -24,7 +24,7 @@ AS_IF([sleep 0.001 2>/dev/null], 
[am_cv_sleep_fractional_seconds=true],
 # nanosecond, matching clock_gettime.  However, it is probably not
 # possible to delay execution of a shell script for less than one
 # millisecond, due to process creation overhead and scheduling
-# granularity, so we don't check for anything finer than that.
+# granularity, so we don't check for anything finer than that. (See below.)
 AC_DEFUN([_AM_FILESYSTEM_TIMESTAMP_RESOLUTION], [dnl
 AC_REQUIRE([_AM_SLEEP_FRACTIONAL_SECONDS])
 AC_CACHE_CHECK([filesystem timestamp resolution], 
am_cv_filesystem_timestamp_resolution, [dnl
@@ -34,6 +34,9 @@ am_cv_filesystem_timestamp_resolution=2
 # Only try to go finer than 1s if sleep can do it.
 am_try_resolutions=1
 if $am_cv_sleep_fractional_seconds; then
+  # Even a millisecond often causes a bunch of false positives,
+  # so just try a hundredth of a second. The time saved between .001 and
+  # .01 is not terribly consequential.
   am_try_resolutions="0.01 0.1 $am_try_resolutions"
 fi
 
@@ -48,12 +51,13 @@ rm -f conftest.ts?
 : > conftest.ts3
 
 # Make sure ls -t actually works.  Do 'set' in a subshell so we don't
-# clobber the current shell's arguments.
+# clobber the current shell's arguments. (Outer-level square brackets
+# are for m4; be careful, it's easy to get confused.)
 if (
  set X `[ls -t conftest.ts[12]]` &&
  {
-   test "$[*]" != "X conftest.ts1 conftest.ts2" ||
-   test "$[*]" != "X conftest.ts2 conftest.ts1";
+   test "$[]*" != "X conftest.ts1 conftest.ts2" ||
+   test "$[]*" != "X conftest.ts2 conftest.ts1";
  }
 ); then :; else
   # If neither matched, then we have a broken ls.  This can happen
@@ -64,7 +68,7 @@ if (
 ["Bad output from ls -t: \"`[ls -t conftest.ts[12]]`\""],
 [AS_MESSAGE_LOG_FD])
   AC_MSG_FAILURE([ls -t produces unexpected output.
-Make sure there is not a broken alias in your environment.])
+Make sure there is not a broken ls alias in your environment.])
 fi
 
 for am_try_res in $am_try_resolutions; do
@@ -84,11 +88,47 @@ for am_try_res in $am_try_resolutions; do
   test "$[]2" = conftest.ts3 &&
   test "$[]3" = conftest.ts2 &&
   test "$[]4" = conftest.ts1); then
-am_cv_filesystem_timestamp_resolution=$am_try_res
-break
+#
+# Ok, ls -t worked. We have one more thing to check: make.
+# It can happen that everything else supports the subsecond mtimes,
+# but make doesn't, notably on macOS, which ships make 3.81 from
+# 2006 (the last one released under GPLv2). https://bugs.gnu.org/68808
+# 
+# So, first let's create a Makefile:
+rm -f conftest.mk
+echo 'conftest.ts1: conftest.ts2' >conftest.mk
+echo ' touch conftest.ts2' >>conftest.mk
+#
+# Now, running
+#   touch conftest.ts1; touch conftest.ts2; make
+# should touch ts1 because ts2 is newer. This could happen by luck,
+# but most often, it will fail if make's support is insufficient. So
+# test for several consecutive successes.
+# 
+# (We reuse conftest.ts[12] because we still want to modify existing
+# files, not create new ones, per above.)
+n=0
+make_ok=true
+until test $n -eq 4; do
+  echo one > conftest.ts1
+  sleep $am_try_res
+  echo two > conftest.ts2 # ts2 should now be newer than ts1
+  if make -f conftest.mk | grep 'up to date' >/dev/null; then
+make_ok=false
+break # out of $n loop
+  fi
+  n=`expr $n + 1`
+done
+if $make_ok; then
+  # Everything we know to check worked out, so call this resolution good.
+  am_cv_filesystem_timestamp_resolution=$am_try_res
+  break # out of resolution loop
+fi
+# Otherwise, we'll go on to check the next resolution.
   fi
 done
 rm -f conftest.ts?
+# (end _am_filesystem_timestamp_resolution)
 ])])
 
 # AM_SANITY_CHECK

compile finished at Mon May 27 10:01:57 2024

bug#68179: Re: automake-1.16j on OpenBSD

[Karl Berry]

I pushed Bogdan's patches. Listing several functions to look for in
(lib)objc in multiple places doesn't seem ideal, but factoring that out
doesn't seem easy either.

strip -x: no problem.

The general issue:

The AC_PROG_OBJCXX macro already tries to compile a trivial program (of
course), but the test program appears to be valid C++ as well as
ObjC++. What I see in my config.log for, say t/objcxx-deps, is:

| int
| main (void)
| {
| 
|   ;
|   return 0;
| }

That empty line with the ; looks suspicious, but I didn't try to track
it down. (Objc++ is somehow not working with autoconf/automake on my
system, even though it works from the command line. I also see nothing
about Objective anything when I rerun configure. I also seem to vaguely
recall some bug report about this.)

Anyway, I see the objc*.sh automake tests use an #import command to make
the test files valid Objective C(++) but not invalid C(++). I'm not sure
if it makes sense for autoconf to do that, or use some other
Objective-specific construct. Or if that's already happening and I'm
just in some misconfigured situation. --thanks, karl.

bug#70638: [PATCH] doc: Put test-driver option args in separate words, not joined with `='

[Karl Berry]

Hi Mark,

> ... correct the
> documentation and usage messages to describe it accurately, with a
> historical note in the manual explaining the long-standing error 

I finally had a chance to apply this patch. Thank you for your careful
work! I just tweaked a few words in the log message and added one more
sentence in the doc explicitly saying arguments and options were
separated by whitespace. Closing the bug. --thanks again, karl.

bug#68855: wording for user on test suite failure?

[Karl Berry]

I was thinking about making the message when the test suite failure more
explicit  ...

(lib/am/check.am)
+echo "Some test(s) failed.  Please report this to $(PACKAGE_BUGREPORT),";  
  \
+echo "together with the test-suite.log file (gzipped) and your system";
  \
+echo "information.  Thanks.";  
  \

No one has replied or noted anything since I committed the change at the
end of January, so closing ... -k

Re: automake 1.17 release plan?

[Karl Berry]

Hi Christoph,

end of 2023 you shared the news that automake release 1.17 could happen 

Indeed. Unfortunately since then I have had to attend to other priority
projects, and there's no one else driving automake. I hope to be able to
spend some time on automake again soon to bring the release to fruition.
I have no ETA though, as ever. Sorry.

There has been no public communication for the last couple of 
weeks. 

Well, I (or someone) is still replying to questions and bugs on
automake@gnu.org and bug-autom...@gnu.org. Not about the release,
though, granted.

What are your plans regarding 1.17? 

Release as soon as possible.

Are there blockers? 

Yes. The last pretest in December turned up at least one:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68808

It requires hacking a function in sanity.m4 to probe make for its
"subsecond mtime" behavior.

There may be others, I'd have to look at the recent pending bugs.

Is there anything we as the community can help?

Well, a patch for the bug above would certainly be helpful.

Patches in general for any other bugs, especially the recent ones, would
be all to the good.

Other than actual patches, reviewing the other recent pending bugs to
see if any others are important enough to require fixing before the
release, or simple enough to just fix and be done with it, would also be
helpful.  (I know there are a few other patches simply waiting for me to
review and install.)

Beyond that, three years ago I wrote a message requesting more
volunteers. The information is (sadly enough) still current:
https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html

Thanks,
Karl

P.S. BTW, did something happen somewhere that prompted you to send this?
I ask because another person wrote me off-list today with the same
question. Seems a bit much for coincidence.

Re: How to force libtool to use CXX mode?

[Karl Berry]

Automake does have a critical bug in that for a target which only 
optionally has C++ sources, that target is always linked using C++. 

So it should only use C++ if the "option" is selected?
Can you provide a test tree?

Without this issue, the trick of including an empty optional C++
source file in the build would work.

I don't yet understand how all this is playing together ... -k

Re: How to force libtool to use CXX mode?

[Karl Berry]

convince Automake to force libtool to link using the C++ compiler

When there are no C++ sources? Why? Just trying to understand ...

I'm sorry Bob, but I just don't know.  Maybe the just-released
libtool-2.5.0 alpha offers some new help?

If there is some bug in or feature for Automake that would help, I'm
open to suggestions (and patches). It kind of sounds like more on the
libtool side? --sorry, karl.

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

[Karl Berry]

Thanks for the Vala doc patch, Reuben. Installed and closing. --best, karl.

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

[Karl Berry]

so you have to give it all the source files at once, 

Wow.

I guess it is worth documenting this limitation of the current Vala
support. If you agree with my reasoning above, then I will prepare a
documentation patch based on it.

All I know about Vala is what you've written, but given that, I do agree
it would be useful to document it. So a doc patch would be most welcome.

(The doc fixes in the test comments are fine, of course. I will apply
as soon as I have a chance.)

Thanks Reuben. -k

bug#70638: Automake custom-driver interface documentation doesn't match implementation

[Karl Berry]

Hi Mark - thanks for the report.

it seems to me that the least bad approach is to correct the
documentation and usage messages to describe it accurately, with a
historical note in the manual explaining the long-standing error in
previous versions of the documentation.

I agree. Would you be up for writing a draft patch? Given the research
you've already done to send this report, you're certainly more familiar
with the relevant places than me (by several miles :).

I guess that hardly anyone writes Automake test drivers. :-/

I guess so too.

(Yes, I am considering doing this.)

If so ... happy driving :). --thanks again, karl.

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

[Karl Berry]

Reuben, any chance you can whomp up a test for this patch?

I don't see a problem with the change, but it's always better to add a
test against future regressions, etc. --thanks, karl.

bug#70557: Fix compilation of Vala files conditionally added to _SOURCES

[Karl Berry]

Attached, an updated patch that passes the tests. It uses GNU Make
functionality, but this is already required by the Vala support.

Thanks Ruben. I will peruse as soon as I have a chance, if no one else
gets there first ... -k

bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

[Karl Berry]

Per https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649576.html
this was fixed in https://bugs.gnu.org/46744. As I understand it.
Closing.

bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

[Karl Berry]

so whether it is
@NATIVE_FALSE@install-exec-local:
@NATIVE_FALSE@uninstall-local:
or
@NATIVE_FALSE@uninstall-local:
@NATIVE_FALSE@install-exec-local:
depends on some hash table traversal or what.

Thanks for the report. Any chance of a Makefile.am that can reproduce
the problem? I wonder if it's related to the @NATIVE_FALSE@ somehow.

Looking at automake.in, it's not obvious to me where a list is failed to
be sorted. Those -local targets aren't generated by automake itself, so
far as I can see. --thanks, karl.

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Karl Berry]

I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.

I'm not sure GNU explicitly recommends anything. Although the tarball
examples in standards.texi and maintain.texi all use gz, I don't think
even gz is explicitly recommended. (Which seems ok to me.)

Personally, I would support lz4 over zstd simply because more GNU
packages already use lz4.(*) Both lz4 and zstd are quite a bit less
resource-hungry than xz, especially for compression. I don't know if
there is a technical reason to prefer zstd.

In general, I think it can continue to be left up to individual
maintainers, vs. making any decrees. Automake supports them all
(among others). --best, karl.

(*) Looking at a listing of ftp.gnu.org, I see only gmp using zst, and
perhaps a dozen or so packages using lz. Basically always in addition to
another format.

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Karl Berry]

`distcheck` target's prominence to recommend it in the "Standard
Targets for All Users" section of the GCS? 

Replying as an Automake developer, I have nothing against it in
principle, but it's clearly up to the GNU coding standards
maintainers. As far as I know, that's still rms (for anything
substantive)

FWIW, I expect that few users would actually run make distcheck,
regardless of anything in the GCS.  And of those that do, I suspect
there would be many failures because make distcheck is a complex target
that is not, so far as I understand it, intended to be as perfectly
portable or prerequisite-free as other targets. No doubt it could be
improved in that regard. Not a stopper, just my thoughts.

Thanks for the suggestion,
Karl

bug#69908: dist-no-built-sources vs. no-dist-built-sources vs. dist-built-sources

[Karl Berry]

The output I got from this and dist-no-built-sources.log is rather 
interesting. As it looks, the test is indeed broken from the beginning.

Thank you very much, Jens. We'll deal with this asap. Your original
analysis that we simply don't recognize the right option name is looking
correct :) :(.

(Bogdan, want to give it a look? I am consumed with other projects for
the time being.) --thanks, karl.

bug#69908: dist-no-built-sources vs. no-dist-built-sources vs. dist-built-sources

[Karl Berry]

Hi Jens - thanks for the report.

Nevertheless I think there is something wrong here. 

Quite likely. Can you please send an example tree that shows the failure?

 'DIST_BUILT_SOURCES' => !! option 'dist-built-sources',

Hmm. I had a vague impression that the "no-" was automatically
supported, but I'm not seeing it now.

or if it could be broken since 314c55f and the test might not 
work properly for some strange reason?

Certainly possible.

What am I overlooking? What am I doing wrong?

Probably nothing, x 2 :). --thanks again, karl.

Re: C library promoted to C++ linkage due to optional C++ source module

[Karl Berry]

Hi Bob,

It is my opinion that if a library or program 
is linked with C++ libraries (and especially if it is a static build!) 
that it should be linked using the C++ linker.  Likewise, if a library 
or program does not depend on, or contain any C++ code, it should be 
linked with the C linker.

I surely agree, in principle. But that doesn't mean I have the faintest
idea what to change in Automake to make that be the case. You probably
know better than me :). Can you provide (as simple as possible) test cases?

I have a continuing problem that when libtool tests 

bug-libt...@gnu.org for that one, I think ... --best, karl.

bug#68832: [PATCH] Testing: POSIX yacc and C++ linkage

[Karl Berry]

  Attaching a simple patch 

Thanks Bogdan! I pushed those changes.

Marcel, if you're able to try testing from the repo, that would be
great.  Else it hopefully won't be too long before the next pretest
(or, even more optimistically, the next release). -karl

bug#68860: race condition with make recheck

[Karl Berry]

Hi Peter,

The problem seems to be that both $(TESTS) and check_LIBRARIES depend on 
libfoo.a and trigger compilation of foo.cc. 

Thanks much for the report and analysis. What you wrote looks sensible
to me.

My understanding of parallel make is a bit hazy,

Me too :(. If anyone else here has a chance to look into this, that
would be great.

One idea would to change the rule for recheck to

It looks plausible. Another possibility that comes to mind is to make
the recheck target more parallel to all, i.e., with a recheck-am
target. I', not sure.

Please find attached a trimmed down example of the problem.

Thanks again. Will ponder. --best, karl.

bug#68832: Testing: POSIX yacc and C++ linkage

[Karl Berry]

parse1.yy:30:7: error: conflicting declaration of 'void yyerror(const 
char*)' with 'C' linkage
parse1.yy:7:6: note: previous declaration with 'C++' linkage

Thanks much for the careful and complete report.

I think this is another manifestation of what Bogdan fixed in other
cases in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62886. His idea
there was to essentially add an extern "C" only on Solaris, via
sufficient #ifdef's.

In these new cases, I guess braces would be required, so the test code
would end up looking like:

#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
extern "C" {
#endif
int yylex (void) { return std::getchar (); }
void yyerror (const char *s) {}
#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
}
#endif

Although I could try to do this, I can't easily test the result, and I'd
probably mess up the editing. I'm also far from sure that this will
actually solve the problem without introducing new ones.

So maybe you could edit one of the test *.sh files and rerun the test
and see what happens? In case you don't know, you can run a single test
with, e.g.,
  make check TESTS='t/yacc-cxx.sh' keep_testdirs=yes
(the keep_testdirs keeps the .dir/ around so it can be
inspected afterward.)

My proposal to solve the issue is to change affected tests to
require bison instead of yacc.  

A lot of work has gone into making the tests work with Solaris tools
(despite the current failures), so I'm reluctant to throw that
possibility away.

Also, there have been similar bug reports with older versions of bison.
There is no panacea :( ...  --thanks, karl.

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Erik, I think all the automake test problems you reported here have been
resolved (thanks to your excellent debugging). So closing. Leaving
#68808 open until Zack or I have a chance to look into testing of make
for the subsecond mtimes. Thanks again! -k

bug#63161: Issue with mkinstalldirs and symb links

[Karl Berry]

Hi Arnaud - back on this bug from last April, I guess I just don't think
it's the job of mkinstalldirs to follow symlinks. It feels like too big
a change in behavior. I think the real bug here lies in whatever
created the broken symlink in the first place.

So I'm going to close this one. All the best,
Karl

bug#67918: random failures with automake-1.16i

[Karl Berry]

I'm going to close this bug about the random test failures, partly fixed
in #67670 and partly still open in #68808, but nothing to do
here. --thanks, karl.

bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

Those square brackets are M4 quotes to prevent M4 from expanding
$* and $2 itself.

Ah, right. Of course. Good!

The $[*] especially confused me. Just looks so perfectly like an array
reference of some strange kind :). I think it would be a tiny bit
clearer to use $[]*? Or am I missing something again?

More importantly, as far as the make probing goes, I have some other
projects to attend to first. So most likely if you can get to it next
week (fingers crossed for your new machine), that will be sooner than
me. Thanks. -k

[bug#68855] wording for user on test suite failure?

[Karl Berry]

I was thinking about making the message when the test suite failure more
explicit about what to do, as in below. If any comments or criticisms,
let me know.

I was actually inspired to do this not so much to tweak these words, but
because I was thinking of adding yet more instructions about how to help
debug the subsecond mtime stuff (for automake only, of course), i.e.,
setting am_cv_sleep_fractional_seconds=false. But with the new
possibility that checking make's behavior will be enough to obviate
those random failures, that doesn't seem necessary/desirable now.

But having gone to all the trouble of figuring out how to change the
text and which tests need to be changed to keep them in sync, I guess I
still hope people think it's worth it, or at least ok, to make this
change. The output would look like this:


See tests/test-suite.log for debugging.
Some test(s) failed.  Please report this to ,
together with the test-suite.log file (gzipped) and your system
information.  Thanks.


Hopefully I did not break the colorization, but I don't have a good way
to test that. --thanks, karl.

-
test: make bug-reporting message on test failure more explicit.

* NEWS: mention this.
* lib/am/check.am ($(TEST_SUITE_LOG)) : new fn,
new wording.
* t/ax/test-defs.in (failure_footer_text): new wording.
(failure_footer_text_colorized): add red.
* t/ax/tap-summary-aux.sh (failure_footer): use failure_footer_text*.
* t/tap-doc2.sh: change grep.
* t/testsuite-summary-color.sh: likewise.
* t/testsuite-summary-count-many.sh: likewise.
* t/testsuite-summary-count.sh: likewise.
* t/testsuite-summary-reference-log.sh: likewise.
diff --git a/NEWS b/NEWS
index 153cb7733..964d82e8c 100644
--- a/NEWS
+++ b/NEWS
@@ -44,6 +44,10 @@ New in 1.17:
   - The missing script also supports autoreconf, autogen, and perl.
 (https://lists.gnu.org/archive/html/automake-patches/2015-08/msg0.html)

+  - test-suite.log now contains basic system information, and the
+console message about bug reporting on failure has a bit more detail.
+(bug#68746)
+
 * Bugs fixed

   - Generated file timestamp checks handle filesystems with sub-second
diff --git a/lib/am/check.am b/lib/am/check.am
index d210172a6..b6fa3aaad 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -246,6 +246,7 @@ am--force-recheck:
 ## Exists only to be overridden.  See bug#11745.
 AM_TESTSUITE_SUMMARY_HEADER = ' for $(PACKAGE_STRING)'

+## emacs-page
 $(TEST_SUITE_LOG): $(TEST_LOGS)
@$(am__set_TESTS_bases); \
 ## Helper shell function, tells whether a path refers to an existing,
@@ -360,7 +361,7 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
  result_count $$1 "ERROR:" $$error "$$mgn"; \
}; \
 ##
-## Write some basic system info in the log. 
+## Function to write some basic system info in the log. 
output_system_information () \
{ \
 ## Omit the hostname for privacy.  In practice it's a single word?
@@ -372,6 +373,16 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
cat /etc/issue;\
  fi;  \
}; \
+##
+## Function to output the "please report bugs" message.
+   please_report () \
+   { \
+echo "Some test(s) failed.  Please report this to $(PACKAGE_BUGREPORT),";\
+echo "together with the test-suite.log file (gzipped) and your system";  \
+echo "information.  Thanks.";\
+   }; \
+##
+## emacs-page
 ## Write "global" testsuite log.
{   \
  echo "$(PACKAGE_STRING): $(subdir)/$(TEST_SUITE_LOG)" |   \
@@ -379,8 +390,10 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
  create_testsuite_report --no-color;   \
  output_system_information;\
  echo; \
-## What is this line for? It seems to be intended for machine parsing,
-## but I can't find any other reference to it. --karl, 27jan24.
+## What is this line for? It's a Sphinx reStructuredText directive that
+## would insert a table of contents that goes two levels deep on headings.
+## But why is it in test-suite.log? No other references to it are evident.
+## Please inform autom...@gnu.org.
  echo ".. contents:: :depth: 2";   \
  echo; \
  for b in $$bases; do echo $$b; done   \
@@ -403,9 +416,9 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
create_testsuite_report --maybe-color;  \
echo "$$col$$br$$std";  \
if $$success; then :; else  

bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

(Off-topic for the original bug, but for the sake of public discussion ...)

Hi Zack,

It is absolutely not *supposed* to be using shell arrays. 

I guess it's not an array. It's the square bracket syntax that confuses
me. A couple of examples from the fn in sanity.m4:

test "$[*]" != "X conftest.ts1 conftest.ts2" ||
..
test "$[]2" = conftest.ts3 &&
..
etc.

I've never seen anything like that before. Searching online, supposedly
$[...] means arithmetic expansion, but clearly that's not what is going
on here. I don't know what it means. Seems like just "$2" (for example)
is intended? I feel like I'm missing/forgetting something basic.

Sorry I didn't read the code when you submitted it originally :(.

Thanks,
Karl

bug#68808: subsecond mtime discovery code insufficient

[Karl Berry]

Hi Erik - following up on your final comment in #68119:

P.P.S. It still needs
export am_cv_sleep_fractional_seconds=false
to correctly run the tests on macOS.  Without that, 75-90 tests fail.

Maybe we can try to figure out why the code that tries to automatically
discern whether subsecond mtimes are supported is insufficient? It seems
there is something different about the mac filesystem (or something). So
I suspect there will be problems on other systems, too.

If there are any test(s) which more or less consistently fail without
the override the sleep_fractional_seconds, maybe we can discern why
those tests are failing. I am dearly hoping not to have inspect every
single test and scatter $sleep commands everywhere.

Meanwhile, the code that tries to figure out if subsecond mtimes are
supported is in m4/sanity.m4, function
_AM_FILESYSTEM_TIMESTAMP_RESOLUTION.  It essentially writes to three
files and sleeps for the trial resolution between them, starting at a
hundredth of a second. Then, if ls -t sorts in the right order, it
assumes that resolution is ok.

For one thing, just to get a grip on reality, maybe you could try
running those commands by hand and see what the result is.  I'm guessing
the Mac (and its sleep command?) do support subsecond mtimes in reality.

  am_try_res=.001
  echo alpha > conftest.ts1
  sleep $am_try_res
  echo beta > conftest.ts2
  sleep $am_try_res
  echo gamma > conftest.ts3
  ls -t conftest.ts?

The result should be conftest.ts3 first, then ts2, then ts1.

But, looking at that code, I belatedly see that shell arrays are being
used. At least I think so. It wouldn't surprise me if the mac /bin/sh
doesn't support arrays. But that should result in assuming subsecond
mtimes are not supported when they are, instead of the reverse. Anyway,
I don't think we can assume arrays, so I'll have to think about that.

But the important thing is why so many tests fail on your system when
subsecond mtimes are enabled (and succeed when not). --thanks, karl.

bug#19692: "rm -f" without file operands specified displays error and exits with status 1 on QNX 6.3.2

[Karl Berry]

When I run ‘make check’, it fails after
passing t/pm/Wrap.pl with the following error:
sh: >&3 : bad file descriptor
tap-driver.sh: fatal: I/O or internal error

Thanks for trying, though sorry to see that result. It's not clear to me
what test is failing or what the environment is. File descriptor 3 is
used in tap-driver.sh, but seemingly not in a complicated way.

If you have time, please try running (without any -j, for simplicity):
  make VERBOSE=1 TESTS_ENVIRONMENT='echo RUNNING: "$$f";' check >chkout 2>&1

And, assuming it still fails, send the resulting
chkout and test-suite.log files (gzipped is best).

The TESTS_ENVIRONMENT value should print "RUNNING: " when a test
is begun, as well as the usual report when a test is finished. --thanks, karl.

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Hi Erik - yay for near-success :).

  case $(echo "$files" | wc -l | sed 's/^ *//') in 4|6) ;; *) false;; esac

I went with that sed.

because "wc -l" prints some spaces in front of the number (at least
on macOS).

I'm surprised this has not been seen already. But fine.
At least it's easy one to fix.

export PYTHON=python3
to verify that it works with python 3.xx.

Fingers crossed.

P.P.S. It still needs
export am_cv_sleep_fractional_seconds=false
to correctly run the tests on macOS.  Without that, 75-90 tests fail.

I'll write separately about that, since this bug is already plenty long :).

Thanks,
Karl

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

  The attached patch fixes the tests for Python 3.12 

Thank you Bogdan! Looks good to me. Installed.

  (and, hopefully later ones), 

Maybe until Python 3.12.2, anyway. --thanks, karl.

bug#19692: "rm -f" without file operands specified displays error and exits with status 1 on QNX 6.3.2

[Karl Berry]

I was able to bootstrap, configure, build and install
automake-1.16j. 

Great!

Is there any other testing I should do?

If you're up for it, you could run make -j8 check (or -jwhatever) just
to see if other tests fail. (It will take several hours to run without
the -j, although unfortunately the -j might also induce spurious
failures. Always looking for more data about this to try to make things
more robust.)

Thanks,
Karl

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Hi Erik - thanks for the continued testing.

Hi, Karl.  I get an error on "make" because there is no "makeinfo"
command on macOS.  

Well, since you've come this far, you could try installing the texinfo
package, if you have Perl.

Or perhaps it would be enough to
  touch doc/automake.info doc/automake-history.info 

This didn't happen with the git clone from several weeks ago. 

That's surprising to me. It's normal for makeinfo to be required when
building from the dev sources. It's not required when building from a
release (or pretest), since .info are included in release tarballs
precisely to avoid this dependency.

Or maybe I'm forgetting something about building from the repo, in which
case I hope someone here will enlighten us :). --thanks again, karl.

purpose of line ".. contents:: :depth: 2" in test-suite.log?

[Karl Berry]

Does anyone know what this line in automake-generated test-suite.log
files is used by or intended for?

. contents:: :depth: 2

It appears to be machine-parsable, but I can't find any reference to it
in the code or the doc. There doesn't seem to be anything that outputs
:depth: 3 (or anything else), either. The above is just a static string
in lib/am/check.am:

  echo ".. contents:: :depth: 2";   \

Just wondering. I don't plan to change it. --thanks, karl.

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Hi Erik,

FAIL: t/aclocal-deleted-header-aclocal-amflags
FAIL: t/aclocal-deleted-header

I'm not sure, but I think the idea of those tests, and others, is that
after making the various changes to the configure setup, running make
should suffice to rebuild everything. Because that's what is most
convenient and what people (including me :) expect.

So I added some $sleep commands before file modifications instead of
rerunning all the autotools. I hope it will suffice.  I'm mostly just
groping in the dark about these timing issues :(.

FAIL: t/aclocal-deps
FAIL: t/subdir-add2-pr46

Similarly added $sleep commands.

FAIL: t/yacc-mix-c-cxx

Moved the #include  to before the "using" statements,
following the other yacc C++ tests.

FAIL: t/py-compile-basedir

That one I don't know. py-compile has used importlib for quite a while.
But some changes have been made, so maybe try the current version, and
if it still fails (as it probably will), send the log?

If you have time and energy to try testing out of the git repository
(git clone git://git.savannah.gnu.org/automake.git),
the above changes are committed now. If not, I hope it won't be long
until the next (and last?!) pretest.

Thanks for all,
Karl

[bug#68746] system information in test-suite.log?

[Karl Berry]

I installed this change to emit system info in test-suite.log.  I tried
to write it so any failure would be ignored, since it's not critical
information.  We'll see. -k

[bug#68746] system information in test-suite.log?

[Karl Berry]

I had the idea that it would be helpful to put basic system information
into test-suite.log, as shown below. Although most people reporting bugs
are good about including their system info, not everyone does. And
details are good.

I figured the output of uname -a and /etc/os-release || /etc/issue would
be enough to go on. That certainly won't cover all systems, but if
nothing shows up, we'll be no worse off. I eliminated the local host
name from uname -a for privacy, just in case. I don't think anything
else in there is at all problematic.

I don't think anything anything parses test-suite.log with such rigidity
that adding some lines near the beginning will cause problems, and
automake's own make check didn't care, but I guess I don't know for sure.

If anyone sees a problem with this, let me know. --thanks, karl.


   GNU Automake 1.16.90: ./test-suite.log


# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

Linux  5.14.0-362.18.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jan 24 23:11:18 
UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"

. contents:: :depth: 2

--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -356,11 +359,25 @@ $(TEST_SUITE_LOG): $(TEST_LOGS)
  result_count $$1 "XPASS:" $$xpass "$$red"; \
  result_count $$1 "ERROR:" $$error "$$mgn"; \
}; \
+##
+## Write some basic system info in the log. 
+   output_system_information () \
+   { \
+## Omit the hostname for privacy.  In practice it's a single word?
+  echo;\
+ (uname -a | awk '{$$2=""; print}') 2>&1; \
+ if test -r /etc/os-release; then \
+   sed 8q /etc/os-release;\
+ elif test -r /etc/issue; then\
+   cat /etc/issue;\
+ fi;  \
+   }; \
 ## Write "global" testsuite log.
{   \
  echo "$(PACKAGE_STRING): $(subdir)/$(TEST_SUITE_LOG)" |   \
$(am__rst_title);   \
  create_testsuite_report --no-color;   \
+ output_system_information;\
  echo; \
  echo ".. contents:: :depth: 2";   \
  echo; \

bug#23563: MKS Platform component 9.X - unable to configure parallel, performing "export ACCEPT_INFERIOR_RM_PROGRAM=YES" doesn't work

[Karl Berry]

The email address for the OP bounced. So closing this one.

bug#19692: "rm -f" without file operands specified displays error and exits with status 1 on QNX 6.3.2

[Karl Berry]

Hi Matt - back in 2015
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692, sorry for the
delayed reply) you reported that your system failed the rm -f test. 

For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)

If you have a chance to try an automake pretest to confirm this
(downloadable from https://alpha.gnu.org/gnu/automake-1.16j.tar.gz),
that would be great. --thanks, karl.

bug#22074: unixware 7.1.4 rm command

[Karl Berry]

Hi Jarkko - back in 2015
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074, sorry for the
delayed reply) you reported that your system failed the rm -f test. 

For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)

If you have a chance to try an automake pretest to confirm this
(downloadable from https://alpha.gnu.org/gnu/automake-1.16j.tar.gz),
that would be great. --thanks, karl.

bug#23563: MKS Platform component 9.X - unable to configure parallel, performing "export ACCEPT_INFERIOR_RM_PROGRAM=YES" doesn't work

[Karl Berry]

Hi Bart - back in 2016
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23563, sorry for the
delayed reply) you reported that your system failed the rm -f test. 

For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)

If you have a chance to try an automake pretest to confirm this
(downloadable from https://alpha.gnu.org/gnu/automake-1.16j.tar.gz),
that would be great. --thanks, karl.

bug#68674:

[Karl Berry]

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

[Karl Berry]

Guess it's time to close this one about the Python scheme to use with
Debian. We'll see how it turns out with the next pretest ... --thanks, karl.

[bug#67670] [PATCH] Revise tests for file mtime resolution again.

[Karl Berry]

Guess it's time to close this one about the subsecond mtimes, and we'll
see what happens next time. (For reference: see also
https://bugs.gnu.org/68325 where we don't try for a millisecond any more ...)

[bug#68674] recommending autoreconf -f when version mismatch

[Karl Berry]

The patch below changes the wording of the "version mismatch" errors to
recommend running autoreconf -f. If anyone sees any problems with the
idea, or the wording, let me know.

I discovered this when trying out the last automake pretest. After
configuring with the new automake, I then went back to the released
automake version, provoking the error:

  configure.ac:26: error: version mismatch.  This is Automake 1.16.5,
  configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
  configure.ac:26: comes from Automake 1.16j.  You should recreate
  configure.ac:26: aclocal.m4 with aclocal and run automake again.

However, running aclocal && automake did not change anything. The 
problem was not (just) aclocal.m4, but the autom4te.cache/ files, which
aclocal and automake do not touch.

The new message is:

  configure.ac:6: error: version mismatch.  This is Automake 1.16.90,
  configure.ac:6: but the definition used by this AM_INIT_AUTOMAKE
  configure.ac:6: comes from Automake 1.16.5.  You should run
  configure.ac:6: autoreconf -f (or otherwise erase all old files, run
  configure.ac:6: aclocal to recreate aclocal.m4, and rerun automake).

I also tweaked the manual to suggest autoreconf in another place.

Comments/corrections/criticisms/whatever welcome ... --thanks, karl.

-
automake: recommend autoreconf -f with version mismatches.

* bin/automake.in (scan_autoconf_traces): change error
to suggest running autoreconf -f. The version mismatch is
most likely to happen due to the cache files, which
aclocal && automake (the previous recommendation) does not delete.
(scan_autoconf_files): likewise.
* doc/automake.texi (Auto-generating aclocal.m4): mention autoreconf.
Other minor wording changes.
diff --git a/bin/automake.in b/bin/automake.in
index f568773eb..0499d81eb 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5442,8 +5442,9 @@ sub scan_autoconf_traces
  error ($where,
 "version mismatch.  This is Automake $VERSION,\n" .
 "but the definition used by this AM_INIT_AUTOMAKE\n" .
-"comes from Automake $args[1].  You should recreate\n" .
-"aclocal.m4 with aclocal and run automake again.\n",
+"comes from Automake $args[1].  You should run\n" .
+"autoreconf -f (or otherwise erase all old files,\n" .
+"recreate aclocal.m4 with aclocal, and rerun automake).",
 # $? = 63 is used to indicate version mismatch to missing.
 exit_code => 63)
if $VERSION ne $args[1];
@@ -5621,9 +5622,10 @@ sub scan_autoconf_files ()
  if (-f 'aclocal.m4')
{
  error ($seen_init_automake,
-"your implementation of AM_INIT_AUTOMAKE comes from " .
-"an\nold Automake version.  You should recreate " .
-"aclocal.m4\nwith aclocal and run automake again",
+ "your implementation of AM_INIT_AUTOMAKE comes from\n" .
+ "an old Automake version.  You should run\n" .
+ "autoreconf -f (or otherwise erase all old files, run\n" .
+ "aclocal to remake aclocal.m4, and rerun automake).",
 # $? = 63 is used to indicate version mismatch to missing.
 exit_code => 63);
}
@@ -5632,8 +5634,8 @@ sub scan_autoconf_files ()
  error ($seen_init_automake,
 "no proper implementation of AM_INIT_AUTOMAKE was " .
 "found,\nprobably because aclocal.m4 is missing.\n" .
-"You should run aclocal to create this file, then\n" .
-"run automake again");
+"You should run autoreconf -f (or aclocal to create\n" .
+"this file, then rerun automake).");
}
}
 }
diff --git a/doc/automake.texi b/doc/automake.texi
index ecefe2dc6..d30905e0f 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3276,7 +3276,7 @@ macros installed in a system-wide directory; 
@pxref{aclocal Invocation}).

 @node aclocal Invocation
 @section Auto-generating aclocal.m4
-@c This node used to be named "Invoking automake".  This @anchor
+@c This node used to be named "Invoking aclocal".  This @anchor
 @c allows old links to still work.
 @anchor{Invoking aclocal}

@@ -3335,9 +3335,15 @@ autoconf, The Autoconf Manual}) in order to trace the 
macros that are
 used, and omit from @file{aclocal.m4} all macros that are mentioned
 but otherwise unexpanded (this can happen when a macro is called
 conditionally).  @command{autom4te} is expected to be in the
-@env{PATH}, just as @command{autoconf}.  Its location can be
+@env{PATH}, just like @command{autoconf}.  Its location can be
 overridden using the @env{AUTOM4TE} environment variable.

+Although this section explains the details of 

bug#68037:

[Karl Berry]

bug#68274: automake 1.16j nonnumerical version confuses scripts

[Karl Berry]

I changed the pretest version to 1.16.90. Closing.

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

[Karl Berry]

Hi Stefano,

I'm not aware of anyone else using posix_local.

Well, I don't know how to check for the deb_system scheme being
present, so I made the assumption. How does this change look?
Are the descriptions correct?

I also pulled out the common "scheme-setting" code into a variable.

Thanks,
Karl

-
python: use deb_system instead of posix_local if prefix = /usr.

Continuing with https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412.

* m4/python.m4 (AM_PATH_PYTHON) :
factor out common scheme-related code to this new variable.
If the scheme is posix_local and the prefix is /usr,
use deb_system (for Debian package builds).
* NEWS: more explanations (and unrelated references, en passant).
diff --git a/NEWS b/NEWS
index 2b2da0908..153cb7733 100644
@@ -67,10 +70,15 @@ New in 1.17:
   - Compiling Python modules with Python 3.5+ uses multiple optimization
 levels. (bug#38043)

-  - The installation directory for Python files again defaults to
-"site-packages" under the usual installation prefix, even on systems
-(generally Debian-based) that would normally use the "dist-packages"
-subdirectory under /usr/local. (bug#54412, bug#64837)
+  - If the Python installation "scheme" is set to posix_local (Debian),
+it is reset to either deb_system (if the prefix = /usr), or
+posix_prefix (otherwise). (bug#54412, bug#64837)
+
+  - As a result of the Python scheme change, the installation directory
+for Python files again defaults to "site-packages" under the usual
+installation prefix, even on systems (generally Debian-based) that
+would normally use the "dist-packages" subdirectory under
+/usr/local.

   - When compiling Emacs Lisp files, emacs is run with --no-site-file to
 disable user config files that might hang or access the terminal;
diff --git a/m4/python.m4 b/m4/python.m4
index f90c73d93..0b1db2689 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -237,7 +237,21 @@ try:
 if python_implementation() == 'CPython' and sys.version[[:3]] == '2.7':
 can_use_sysconfig = 0
 except ImportError:
-pass"
+pass" # end of am_python_setup_sysconfig
+
+  # More repeated code, for figuring out the installation scheme to use.
+  am_python_setup_scheme="if hasattr(sysconfig, 'get_default_scheme'):
+  scheme = sysconfig.get_default_scheme()
+else:
+  scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+  if '$am_py_prefix' == '/usr':
+scheme = 'deb_system' # should only happen during Debian package builds
+  else:
+# Debian's default scheme installs to /usr/local/ but we want to
+# follow the prefix, as we always have.
+# See bugs#54412, #64837, et al.
+scheme = 'posix_prefix'" # end of am_python_setup_scheme

   dnl emacs-page Set up 4 directories:

@@ -258,15 +272,7 @@ except ImportError:
 $am_python_setup_sysconfig
 if can_use_sysconfig:
   try:
-if hasattr(sysconfig, 'get_default_scheme'):
-  scheme = sysconfig.get_default_scheme()
-else:
-  scheme = sysconfig._get_default_scheme()
-if scheme == 'posix_local':
-  # Debian's default scheme installs to /usr/local/ but we want to
-  # follow the prefix, as we always have.
-  # See bugs#54412, #64837, et al.
-  scheme = 'posix_prefix'
+$am_python_setup_scheme
 sitedir = sysconfig.get_path('purelib', scheme, 
vars={'base':'$am_py_prefix'})
   except:
 sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
@@ -300,6 +306,7 @@ sys.stdout.write(sitedir)"`
   dnl 3. pyexecdir: directory for installing python extension modules
   dnl(shared libraries).
   dnl Query sysconfig or distutils for this directory.
+  dnl Much of this is the same as for prefix setup above.
   dnl
   AC_CACHE_CHECK([for $am_display_PYTHON extension module directory 
(pyexecdir)],
   [am_cv_python_pyexecdir],
@@ -312,13 +319,7 @@ sys.stdout.write(sitedir)"`
 $am_python_setup_sysconfig
 if can_use_sysconfig:
   try:
-if hasattr(sysconfig, 'get_default_scheme'):
-  scheme = sysconfig.get_default_scheme()
-else:
-  scheme = sysconfig._get_default_scheme()
-if scheme == 'posix_local':
-  # See scheme comments above.
-  scheme = 'posix_prefix'
+$am_python_setup_scheme
 sitedir = sysconfig.get_path('platlib', scheme, 
vars={'platbase':'$am_py_exec_prefix'})
   except:
 sitedir = sysconfig.get_path('platlib', 
vars={'platbase':'$am_py_exec_prefix'})

compile finished at Sat Jan 20 14:31:01 2024

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

[Karl Berry]

Hi Stefano,

returning automake behaviour back to what it used to be.

That seems like a good outcome to me. I wasn't actually looking to
improve on that result :).

if default_scheme == 'posix_local':  # Debian

posix_local only exists on Debian, not any other system?
The name is generic.

In any case, I guess it would be safe if it's possible to check if the
deb_system scheme exists, and only do the special casing if both
posix_local and deb_system are present.

Wdyt? --thanks, karl.

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

[Karl Berry]

Gianfranoc, Stefano - thanks much for the patch wrt Automake and Debian
Python posix_local vs. posix_prefix. Below is what I installed -- the
code change is substantively the same as what you wrote; I just took the
extra try..catch that Bogdan added.

I changed the paragraph in the manual about pythondir. If you could look
at it, that would be great. Is it correct that the basic idea is that,
with this change, Automake again follows --prefix (and related) + using
site-packages instead of Debian's defaults of /usr/local and
dist-packages? --thanks, karl.

---
python: use posix_prefix instead of posix_local on Debian.

>From https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#17.
(Patch slightly adapted by Bogdan from original by Gianfranco,
as posted by Stefano Rivera in message#14.)

* m4/python.m4 (AM_PATH_PYTHON): replace Debian's posix_local
scheme with posix_prefix.
* doc/automake.texi (Python) : say a bit more.
* NEWS: mention this.
diff --git a/NEWS b/NEWS
index c53573a0a..2b2da0908 100644
--- a/NEWS
+++ b/NEWS
+  - The installation directory for Python files again defaults to
+"site-packages" under the usual installation prefix, even on systems
+(generally Debian-based) that would normally use the "dist-packages"
+subdirectory under /usr/local. (bug#54412, bug#64837)
+
   - When compiling Emacs Lisp files, emacs is run with --no-site-file to
 disable user config files that might hang or access the terminal;
 and -Q is not used, since its support and behavior varies. (bug#58102)
diff --git a/doc/automake.texi b/doc/automake.texi
index c63279a9e..ecefe2dc6 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7987,8 +7987,18 @@ building Python extensions.

 @item pythondir
 @cindex @file{site-packages} Python directory
-The directory name for the @file{site-packages} subdirectory of the
-standard Python install tree.
+@cindex @file{dist-packages} Python directory
+The subdirectory of the Python install tree in which to install Python
+scripts. By default this is, on all systems,
+@file{$PYTHON_PREFIX/lib/python@var{version}/site-packages}, where
+@code{$PYTHON_PREFIX} is described above, and @var{version} is the
+Python version.  (For those knowledgeable about Python installation
+details: systems generally have their own Python installation scheme,
+such as @code{posix_local} on Debian and related (as of
+Python@tie{}3.10), which ends up using a directory named
+@file{dist-packages}; Automake uses the @code{posix_prefix} scheme and
+@file{site-packages}.)
+@c https://bugs.gnu.org/54412 et al.

 @item pkgpythondir
 This is the directory under @code{pythondir} that is named after the
diff --git a/m4/python.m4 b/m4/python.m4
index 2de57c52a..f90c73d93 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -243,9 +243,9 @@ except ImportError:

   dnl 1. pythondir: where to install python scripts.  This is the
   dnlsite-packages directory, not the python standard library
-  dnldirectory like in previous automake betas.  This behavior
+  dnldirectory as in early automake betas.  This behavior
   dnlis more consistent with lispdir.m4 for example.
-  dnl Query distutils for this directory.
+  dnl Query sysconfig or distutils (per above) for this directory.
   dnl
   AC_CACHE_CHECK([for $am_display_PYTHON script directory (pythondir)],
   [am_cv_python_pythondir],
@@ -257,7 +257,19 @@ except ImportError:
am_cv_python_pythondir=`$PYTHON -c "
 $am_python_setup_sysconfig
 if can_use_sysconfig:
-  sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
+  try:
+if hasattr(sysconfig, 'get_default_scheme'):
+  scheme = sysconfig.get_default_scheme()
+else:
+  scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+  # Debian's default scheme installs to /usr/local/ but we want to
+  # follow the prefix, as we always have.
+  # See bugs#54412, #64837, et al.
+  scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('purelib', scheme, 
vars={'base':'$am_py_prefix'})
+  except:
+sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
 else:
   from distutils import sysconfig
   sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')
@@ -287,7 +299,7 @@ sys.stdout.write(sitedir)"`

   dnl 3. pyexecdir: directory for installing python extension modules
   dnl(shared libraries).
-  dnl Query distutils for this directory.
+  dnl Query sysconfig or distutils for this directory.
   dnl
   AC_CACHE_CHECK([for $am_display_PYTHON extension module directory 
(pyexecdir)],
   [am_cv_python_pyexecdir],
@@ -299,7 +311,17 @@ sys.stdout.write(sitedir)"`
am_cv_python_pyexecdir=`$PYTHON -c "
 $am_python_setup_sysconfig
 if can_use_sysconfig:
-  sitedir = sysconfig.get_path('platlib', 
vars={'platbase':'$am_py_exec_prefix'})
+  try:
+if hasattr(sysconfig, 'get_default_scheme'):
+  scheme = 

bug#68325: sanity.m4: a millisecond is too fast?

[Karl Berry]

I installed the change to only try for a hundredth of a second.
We'll see if it helps. -k

bug#64837: FAIL: t/python-prefix

[Karl Berry]

I installed Bogdan's version of Stefano's patch from #54412.
Fingers crossed. -k

[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list

[Karl Berry]

Sorry to be a curmudgeon, but I don't see an advantage to merely
dynamically synthesizing the static list of versions. If anything, I
think statically listing everything in text is clearer and less
error-prone.

What would be an improvement is to not to have this list of versions at
all. I guess we could consider each element of PATH in turn, looking for
executables named python\d\.?\d+ (something like that), but it seems
fragile not to use AC_PATH_PROGS. Dealing with .exe, sorting the
resulting possible set of names correctly ("by reverse version"), and
other niggling details.

So I guess in the end my inclination is to leave bad enough alone. Might
as well close this.

Thanks to everyone for the input.
Karl

P.S. As for Python 4: no, I was not being facetious about Python's
demonstrated lack of interest in compatibility. It doesn't seem like it
would hurt anything much to add python4 and python4.0, but I'm content
to never mind that, and await developments.

[bug#68416] [PATCH] python: add 3.20 - 3.16 to the version search list

[Karl Berry]

With Python 3.12 out now, and 3.13 out in ~9 months, the existing runway
is running out.  Bump up to 3.20 for the next Automake release.

Applied, thanks.

Not proposing to try anything for our upcoming release, but I wonder if
there is some more general way to handle Python versions? We don't have
to laboriously list every possible version for anything else.

As things are, I'm tempted to include 4.20-4.1 too, because their next
major incompatibility will probably come sooner rather than later ...

wdyt? --thanks, karl.

bug#68274: automake 1.16j nonnumerical version confuses scripts

[Karl Berry]

there is nothing requiring or restricting the current version behavior
other than "it's always been this way".  

True.

but that doesn't mean it's better.

No way to know what release or test scripts might be relying on the
current convention. Changing for the sake of change doesn't seem good.

there's no reason we couldn't use more modern convention here like -rc#.

I don't much like it, since "rc" always makes me think first of rc
files. It also wouldn't fix the problem in jami (still not numeric).

Another alternative: when this came up 30-odd years ago, rms changed the
GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
that would at least have the benefit of following a recommendation, and
as a side effect, would also fix jami's assumption (poor practice though
it is, IMHO).
https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases

Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
(rough guess with some grep counting) the .90 convention is by far the
most common approach (a couple thousand), followed by the suffix letter
a la automake (~750 releases), followed by -rc (~360). -hexid and -date
are both trailing the field. Other random conventions also present.

It all feels like bikeshedding to me, so my inclination is to do
nothing.  If we do change, I think we should use .90.  --best, karl.

[bug#68325] sanity.m4: a millisecond is too fast?

[Karl Berry]

The plethora of bug reports from the last pretest make me believe that
many systems simply cannot (currently) reliably handle a millisecond
difference in mtime. Despite the latest careful test that Zack
implemented _AM_FILESYSTEM_TIMESTAMP_RESOLUTION, pretesters continued to
report "random" errors.

My current idea is to only try for a hundredth of a second. This makes
the automake test suite take a few extra minutes to run (something like
12 vs. 10, in my trials), but hopefully will generate less false
positives, which would be well worth it, IMHO.

It seems impossible to truly test for a capable (file)system, or
otherwise figure out the underlying problem. At least, I don't have any
good ideas. The whole idea of the am test command $sleep seems like a
bogus workaround to me. On the other hand, failing a true fix, I think
it needs to be added in many more places, with the advent of subsecond
mtimes. Debugging all this is nowhere on my list :(.

Anyway, if anyone has any ideas about how to better proceed, please
speak up. Else I'll install this trivial patch, and we'll see how the
next pretest goes. --thanks, karl.

--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -34,7 +34,7 @@ am_cv_filesystem_timestamp_resolution=2
 # Only try to go finer than 1s if sleep can do it.
 am_try_resolutions=1
 if $am_cv_sleep_fractional_seconds; then
-  am_try_resolutions="0.001 0.01 0.1 $am_try_resolutions"
+  am_try_resolutions="0.01 0.1 $am_try_resolutions"
 fi
 
 # In order to catch current-generation FAT out, we must *modify* files

bug#68274: automake 1.16j nonnumerical version confuses scripts

[Karl Berry]

Carl - sorry, you'll need to adjust your script.  Automake and other
packages have used letters for pretests for decades, and it's not
plausible to change now.

Also, I have the impression that other packages use random git hexids in
their pretest releases, which aren't numeric either. -k

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

FYI, macOS has an old bison (version 2.3 from 2006).

I'm not sure if automake theoretically support bison going back that
far, but I'm not going to worry about it since many errors disappear
with the new bison. Thanks for thinking of that.

In both aclocal-deleted-header.sh and
aclocal-deleted-header-aclocal-amflags.sh, isn't an additional
"$ACLOCAL -I . && $AUTOMAKE && $AUTOCONF && ./configure" needed
before the second $MAKE?

Very likely. I saw similar omitted autocalls in other tests.
I will look as soon as I have a chance. --thanks again, karl.

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Using am_cv_sleep_fractional_seconds=false dropped it to 7-11 tests failing.

Erik, thanks for all the trials and detailed analysis.
Nothing is immediately clear to me either :(, but I'll take a look. -k

bug#67894: automake-1.16i pretest available: please test

[Karl Berry]

It seems to work. 'make check -j16' goes through and since it seemed to 
be of a random nature previously I ran the individual test repeatedly 
and it passed every time.

Thanks for confirming, Peter. Myriad other problems have been reported,
so it's nice to have one that actually got fixed :). Closing this out ...

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

92 tests fail on 1.16j

Thanks for trying, though a sad result. I have a hunch that a lot of the
failures are timing issues. Although Automake thinks your system
"should" work with a 1-millisecond sleep at various points (I gather
you're already using autoconf-2.72), maybe there are problems in
practice.

If you're up for it, please try setting this variable in the environment
  am_cv_sleep_fractional_seconds=false
  export am_cv_sleep_fractional_seconds
(Bourne-compatible shell syntax, if you're using a C shell, I assume you
know what to do. :)

And then make distclean (to remove the leftovers) and the same configure
&& etc. That's my only immediate idea ... --thanks again, karl.

bug#68165: automake-1.16j on Solaris 11

[Karl Berry]

  /usr/bin/lex --version
and that command reads from standard input:

Thanks Bruno. I installed the patch.

As for the other (non-ignored) failures, here and in your other reports
today ... I can't get far with such system-dependent failures. Any
chance you have time to delve into them? I know that's asking a lot.
I will look at the logs, but have little confidence I'll have any ideas
for fixes. --thanks, karl.

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Hi Erik - thanks for the follow-up. Now I understand. You were testing
automake-1.16.5. But you sent it so soon after we released a pretest, I
didn't notice, and thought you were testing the pretest :).

These test failures (among lots of other things) are supposedly fixed in
the current sources. Could you easily test
https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.xz
?

No need to install it, just ./configure && make && make -j8 check;
for whatever value of "8" you like :). --thanks, karl.

bug#68151: automake-1.16j on Alpine Linux

[Karl Berry]

  - does not understand the option '--best', only '-1' ... '-9'.
  - understands the options '-1' ... '-9' only when compressing, not when

Seems a rather unnecessary incompatibility that some system decided not
to support --best in gzip, when it has been available for those same 30
years. Oh well.

Here's a proposed fix. It consists in passing '-9' instead of '--best'.

Thanks. Looks fine to me, and all the tests still passed. Installed,
with a few words in the doc. -k

bug#68141: automake-1.16j on Ubuntu

[Karl Berry]

FAIL: t/python-prefix

Log file is attached.

I think it is the same issue as reported at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64837 .

Thanks for the report. I hope Mike or Bogdan can look at it. I have
trouble discerning fixes for anything Python-related. -k

bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed

[Karl Berry]

Subject: [GNU automake 1.16.5] test-suite 45 tests failed
Clean install of macOS Sonoma 14.2.1 on MacBook Pro M3 max

Thanks for the report, but it seems like something in the environment is
causing trouble. For example, one of the failing tests is
dist-vs-built-sources.sh:

gcc -DPACKAGE_NAME=\"dist-vs-built-sources\" 
-DPACKAGE_TARNAME=\"dist-vs-built-sources\" -DPACKAGE_VERSION=\"1.0\" 
-DPACKAGE_STRING=\"dist-vs-built-sources\ 1.0\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DPACKAGE=\"dist-vs-built-sources\" -DVERSION=\"1.0\" -I.
 -g -O2 -MT foo.o -MD -MP -MF .deps/foo.Tpo -c -o foo.o foo.c
foo.c:2:19: error: call to undeclared library function 'printf' with type 
'int (const char *, ...)'; ISO C99 and later do not support implicit function 
declarations [-Wimplicit-function-declaration]
int main (void) { printf ("%s\n", F); return 0; }
  ^
foo.c:2:19: note: include the header  or explicitly provide a 
declaration for 'printf'

However,  is already included. The test program is these three
lines (h.h is a trivial #define):
#include 
#include "h.h"
int main (void) { printf ("%s\n", F); return 0; }

So the failure doesn't make sense to me.  I have no access to Sonoma or
other way to debug, unfortunately.

The other failures also look like they relate to the test suite programs
in this particular environment, rather than actual Automake
functionality.

Maybe someone else here has an idea or a way to proceed. --thanks, karl.

bug#68066: [PATCH] Support nanoMIPS architecture

[Karl Berry]

+   | nanomips* \

Thanks, but config.{sub,guess} patches need to be sent to
config-patc...@gnu.org. I forwarded your message. --all the best, karl.

automake-1.16j pretest available: please test

[Karl Berry]

The GNU Automake 1.16j development snapshot is now available. Download here:

  https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.xz
  https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.gz

We intend for automake 1.17 to be released soon, essentially with only
bug fixes for whatever is found in this pretest. So please do test if at
all possible.

The main change from 1.16i was another attempt at making the "subsecond
mtime" support reliable and backward compatible. That is, to work with
autoconf-2.72 (which supports subsecond mtimes) and earlier versions
(which don't). See below for the detailed list of changes since the
previous version, as summarized by the NEWS file.

In general, it's our primary goal to preserve compatibility. If this
release of Automake induces failure in a setup that was previously
working, please let us know.

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

Thanks to everyone who has reported problems, contributed patches,
and helped test Automake!

With special thanks to Bogdan, Mike Frysinger, Nick Bowler, and 
Zack Weinberg for their numerous contributions.  This release could not
have happened without them.



New in (what will be) 1.17:

* New features added

  - AM_PATH_PYTHON will, after checking "python", prefer any Python 3
version (latest versions checked first) over any Python 2
version. If a specific version of Python 2 is still needed, the
$PYTHON variable should be set beforehand.

  - AM_PATH_PYTHON will also search for Python versions 3.15 through 3.10.
It previously searched for 3.9 through 3.0. (bug#53530)

  - RANLIB may be overridden on a per-target basis.

  - AM_TEXI2FLAGS may be defined to pass extra flags to TEXI2DVI & TEXI2PDF.

  - New option "posix" to emit the special target .POSIX for make.

  - Systems with non-POSIX "rm -f" behavior are now supported, and the
prior intent to drop support for them has been reversed.
The ACCEPT_INFERIOR_RM_PROGRAM setting no longer exists.

  - Variables using escaped \# will trigger portability warnings, but be
retained when appended.  GNU Make & BSD Makes are known to support it.
(bug#7610)

  - GNU Make's default pattern rules are disabled, for speed and debugging.
(.SUFFIXES was already cleared.) (bug#64743)

  - For Texinfo documents, if a .texi.in file exists, but no .texi, the
.texi.in will be read. Texinfo source files need not be present at
all, and if present, need not contain @setfilename. Then the file name
as given in the Makefile.am will be used.  If @setfilename is present,
it should be the basename of the Texinfo file, extended with .info.
(bug#54063)

  - The missing script also supports autoreconf, autogen, and perl.

* Bugs fixed

  - Generated file timestamp checks handle filesystems with sub-second
timestamp granularity dynamically, greatly speeding up make check,
etc. However, this requires an autom4te from Autoconf 2.72 or later
(or random test failures and other timing problems may ensue), as
well as a Perl, sleep utility, and filesystem that supports
sub-second resolution; otherwise, we fall back to one-second
granularity as before. When everything is supported, a line
`Features: subsecond-mtime' is now printed by automake --version
and autom4te --version. (bug#64756, bug#67670)

  - The default value of $ARFLAGS is now "cr" instead of "cru", to better
support deterministic builds. (bug#20082)

  - Dependency files are now empty, instead of '# dummy', for speed.

  - Compiling Python modules with Python 3.5+ uses multiple optimization
levels. (bug#38043)

  - When compiling Emacs Lisp files, emacs is run with --no-site-file to
disable user config files that might hang or access the terminal;
and -Q is not used, since its support and behavior varies. (bug#58102)

  - Emacs Lisp compilations respects silent make output.

  - Automake no longer incorrectly warns that the POSIX make variables
$(*D) and the like are non-POSIX. Unfortunately, the make
implementations which do not correctly implement all the POSIX
variables are not detected, but this seems to have little impact
in practice. (bug#9587)

  - Pass libtool tags OBJC and OBJCXX for the respective languages.
(bug#67539)

  - distcleancheck ignores "silly rename" files (.nfs* .smb* .__afs*)
that can show up on network file systems.

  - tests: avoid some declaration conflicts for lex et al. on SunOS.
(bug#34151 and others)

  - Pass any options given to AM_PROG_LEX on to AC_PROG_LEX.
(bug#65600, bug#65730)

* Obsolescence:

  - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
released in 2000, is currently the minimum required version.

bug#67894: automake-1.16i pretest available: please test

[Karl Berry]

I get one failure (t/nodef) 

Hi Peter - I hope this random timing bug is fixed now. If you're able to
test from the automake source tree
(https://savannah.gnu.org/projects/automake/), that would be great.
Else the next pretest should be coming along soon. --thanks, karl.

bug#67918: random failures with automake-1.16i

[Karl Berry]

I ran `make check` for this release on Fedora-rawhide and got random
failures. Multiple runs seem to show different failures on all arches 

Hi Fredric - I hope this random timing bug is fixed now. If you're able
to try testing from the automake source tree
(https://savannah.gnu.org/projects/automake/), that would be great.
Else the next pretest should be coming along soon. --thanks, karl.

Re: Typo in NEWS section "New in 1.17" and "New in 1.15"

[Karl Berry]

While reading the announcement for 1.16i, I found a typo in the
NEWS file "New in 1.17" section.

I have also accidentally found a typo in the "New in 1.15"
section, 

Thanks x 2, Hans. Applied.

which might need a line rewrap after the fix.

Nah, it's ok.

I have not systematically looked for typos in any of the
"New in ..." sections older than 1.17.

I ran a spell checker and nothing obvious showed up. Not that that's
conclusive, but it will have to do :). --thanks, karl.

[bug#68037] silent-defaults.sh test needs to rerun automake

[Karl Berry]

MAKE
 AM_SILENT_RULES([no])
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 EOF

+$ACLOCAL
+$AUTOMAKE
 $AUTOCONF

-./configure -C
+./configure
 grep '^AM_DEFAULT_VERBOSITY = 1' Makefile

 ./configure -C --enable-silent-rules
@@ -141,18 +159,21 @@ grep '^AM_DEFAULT_VERBOSITY = 0' Makefile
 ./configure -C --disable-silent-rules
 grep '^AM_DEFAULT_VERBOSITY = 1' Makefile

-# User enables silent mode default after AM_INIT_AUTOMAKE.
+# 
+echo "User enables silent mode default after AM_INIT_AUTOMAKE."
 cat <configure.ac
-AC_INIT([silent-defaults], [1.0])
+AC_INIT([silent-defaults-user-enable-after-am_init], [1.0])
 AM_INIT_AUTOMAKRunning command: git commit \-q \-F \.\/vc\-dwim\-log\-ZjLUtH 
\-\-author\=Karl\ Berry\ \ \-\- 
t\/silent\-defaults\.sh doc\/automake\.texi
E
 AM_SILENT_RULES([yes])
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 EOF

+$ACLOCAL
+$AUTOMAKE
 $AUTOCONF

-./configure -C
+./configure
 grep '^AM_DEFAULT_VERBOSITY = 0' Makefile

 ./configure -C --enable-silent-rules

diff --git a/doc/automake.texi b/doc/automake.texi
index 3f1011922..4de175bd7 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -11468,16 +11468,17 @@ Libtool Sources}).
 * Make verbosity::  Make is verbose by default
 * Tricks For Silencing Make::   Standard and generic ways to silence make
 * Automake Silent Rules::   How Automake can help in silencing make
+* Unsilencing Automake::Showing commands.
 @end menu

 @node Make verbosity
 @section Make is verbose by default

 Normally, when executing the set of rules associated with a target,
-@command{make} prints each rule before it is executed.  This behaviour,
-while having been in place for a long time, and being even mandated by
-the POSIX standard, starkly violates the ``silence is golden'' UNIX
-principle@footnote{See also
+@command{make} prints each rule before it is executed.  This behavior,
+despite having been in place since the beginning of @command{make},
+and being mandated by the POSIX standard, starkly violates the
+``silence is golden'' UNIX principle@footnote{See also
 @uref{http://catb.org/~esr/writings/taoup/html/ch11s09.html}.}:

 @quotation
@@ -11486,24 +11487,28 @@ say nothing.  Well-behaved Unix programs do their 
jobs unobtrusively,
 with a minimum of fuss and bother.  Silence is golden.
 @end quotation

-In fact, while such verbosity of @command{make} can theoretically be
-useful to track bugs and understand reasons of failures right away, it
-can also hide warning and error messages from @command{make}-invoked
-tools, drowning them in a flood of uninteresting and seldom useful
-messages, and thus allowing them to go easily undetected.
+The traditional verbosity of @command{make} is understandable, as it
+is useful, often necessary, in order to understand reasons of
+failures. However, it can also hide warning and error messages from
+@command{make}-invoked tools, drowning them in uninteresting and
+seldom useful messages, and thus allowing them to easily go
+undetected.

-This problem can be very annoying, especially for developers, who usually
+This can be quite problematic, especially for developers, who usually
 know quite well what's going on behind the scenes, and for whom the
-verbose output from @command{make} ends up being mostly noise that hampers
-the easy detection of potentially important warning messages.
+verbose output from @command{make} ends up being mostly noise that
+hampers the easy detection of potentially important warning messages.
+
+So Automake provides some support for silencing @command{make}.

 @node Tricks For Silencing Make
 @section Standard and generic ways to silence Make

-Here we describe some common idioms/tricks to obtain a quieter make
-output, with their relative advantages and drawbacks.  In the next
-section (@ref{Automake Silent Rules}) we'll see how Automake can help
-in this respect, providing more elaborate and flexible idioms.
+Here we describe some common idioms/tricks to obtain a quieter
+@command{make} output, with their relative advantages and drawbacks.
+In the next section (@ref{Automake Silent Rules}) we'll see how
+Automake can help in this respect, providing more elaborate and
+flexible idioms.

 @itemize @bullet

@@ -11515,13 +11520,14 @@ executing it.
 The @option{-s} flag is mandated by POSIX, universally supported, and
 its purpose and function are easy to understand.

-But it also has its serious limitations too.  First of all, it embodies
-an ``all or nothing'' strategy, i.e., either everything is silenced, or
-nothing is; this lack of granularity can sometimes be a fatal flaw.
-Moreover, when the @option{-s} flag is used, the @command{make} output
-might turn out to be too terse; in case of errors, the user won't
-be able to easily see what rule or command have caused them, or even,
-in case of tools with poor error reporting, what the errors were!
+But it also has serious limitations.  First of all, it embodies an
+``all or nothing'' strategy, i.e., either everythin

[bug#67670] [PATCH] Revise tests for file mtime resolution again.

[Karl Berry]

One more follow-up on this. As we saw from the bug reports for the 1.16i
pretest (67894, 67918), the random parallelization failures were back
after this, when autom4te did not support subsecond-mtimes.

As far as I could tell, what was needed was to add
  am_cv_sleep_fractional_seconds=false
which is what the previous sanity.m4 code did when a non-subsecond
autom4te was detected.

With this, my make (dist)check then started reliably succeeding again.
(Though vastly more slowly, of course.)

--- a/t/ax/test-defs.in
+++ b/t/ax/test-defs.in
@@ -193,6 +193,10 @@ case $MTIME_RESOLUTION in
   :
 else
   MTIME_RESOLUTION=1
+  # we must not sleep for fractional seconds when autom4te does not
+  # support subsecond-mtimes, even when sleep supports it. See bug#67670.
+  am_cv_sleep_fractional_seconds=false
+  export am_cv_sleep_fractional_seconds
 fi
   ;;
 esac

My actual commit has a lot of related verbiage, but that additional
assignment is the only substantive change.

Nothing to do here (comments welcome of course), but just wanted to get
this into the bug archive ... --thanks, karl.

bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

[Karl Berry]

Closing this since there's nothing left to do on the automake side.

(Someone new volunteered to take over libtool, BTW, but I see no changes
in the maintainers file as yet. Not sure where that stands.) --best, karl.

[bug#68004] [PATCH] doc: update location of FETCHFILES variable

[Karl Berry]

* HACKING: FETCHFILES has been moved: Makefile.am -> maintainer/maint.mk

Thanks Dimitri. Installed (I tweaked a couple more words while we were
there). (Also closing.) --all the best, karl.

[bug#68003] [PATCH] doc: typos from codespell.

[Karl Berry]

Subject: [bug#68003] [PATCH] doc: typos from codespell.

Thanks Dimitri. Installed as-is. (And closing.) --all the best, karl.

[bug#67868] intentionally unreadable dirs make distcheck fail

[Karl Berry]

I guess no one saw anything obviously wrong with my distcheck permission
fixes (or no one read my screed, for which I wouldn't blame anyone :),
so closing. I still have no clue as to why it started failing "all of a
sudden", but I guess it doesn't really matter. -k

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Karl Berry]

This was changed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67971
and autoconf-2.72 has been released, so closing.

Without Jacob's suggested use of encode(), I see (Jacob, thanks for the
explanations), but Zack, I'm not sure you intended this bug to track
that. Feel free to reopen if so.

Thanks,
Karl

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

[Karl Berry]

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

Regarding automake's running of help2man. I forgot that this is ok
because automake (doc/local.mk) includes a copy of the help2man script
itself in its distribution, instead of including the man pages. Thus all
users generate the man pages as part of doing a normal build.

This is in contrast to autoconf (man/local.mk), which takes the other
approach, of including the man pages and doing the necessary things,
including wrappers for each script, so that users don't generate the man
pages. Which is arguably cleaner, but since no one is complaining about
the automake approach, I don't see a need to change it now.

I updated the "Errors with distclean" node in the automake manual to
more fully describe the situation. I also moved it (as was suggested in
a comment in the manual) to be a subsection of the "Checking the
Distribution" section, and reorganized that section. (No node names were
changed.)

Ok, closing this bug now ... -k

#
doc: more on help2man and "Errors with distclean".

This fixes (the rest of) https://bugs.gnu.org/67891.

* doc/automake.texi (Errors with distclean): make a subsection of
"Checking the Distribution". Contrast help2man usage examples of
Autoconf (includes man pages in distribution) and
Automake (no man pages, distributes the help2man script instead).
(Checking the Distribution): convert subheadings to subsections.
* doc/local.mk: also mention autoconf vs. automake approaches here,
and point to the manual.
(checklinkx): en passant, remove unused checklinkx exclude.
diff --git a/doc/automake.texi b/doc/automake.texi
index 77292288d..3f1011922 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8871,10 +8871,10 @@ a bit, we can say this rule first makes a distribution, 
and then,
 @emph{operating from it}, takes the following steps (in this order):
 @itemize
 @item
-tries to do a @code{VPATH} build (@pxref{VPATH Builds}), with the
+does a @code{VPATH} build (@pxref{VPATH Builds}), with the
 @code{srcdir} and all its content made @emph{read-only};
 @item
-tries to make the printable documentation, if any (with @command{make dvi}),
+makes the printable documentation (with @command{make dvi}), if any,
 @item
 runs the test suite (with @command{make check}) on this fresh build;
 @item
@@ -8893,12 +8893,23 @@ All of these actions are performed in a temporary 
directory.  The
 exact location and the exact structure of such a directory (where the
 read-only sources are placed, how the temporary build and install
 directories are named and how deeply they are nested, etc.) is to be
-considered an implementation detail, which can change at any time; so
-do not rely on it.
+considered an implementation detail, which can change at any time, so
+please do not rely on it.

+@menu
+* DISTCHECK_CONFIGURE_FLAGS::  Overriding configure flags in distcheck.
+* distcheck-hook:: Running commands after distcheck.
+* dvi and distcheck::  Overriding the distcheck doc target.
+* distcleancheck:: Handling files not cleaned.
+* distuninstallcheck:: Overriding the uninstall check.
+* Errors with distclean::
+@end menu
+
+@node DISTCHECK_CONFIGURE_FLAGS
+@subsection @code{DISTCHECK_CONFIGURE_FLAGS}
 @vindex AM_DISTCHECK_CONFIGURE_FLAGS
 @vindex DISTCHECK_CONFIGURE_FLAGS
-@subheading DISTCHECK_CONFIGURE_FLAGS
+
 Building the package involves running @samp{./configure}.  If you need
 to supply additional flags to @command{configure}, define them in the
 @code{AM_DISTCHECK_CONFIGURE_FLAGS} variable in your top-level
@@ -8912,31 +8923,52 @@ over the @command{configure} options @option{--srcdir} 
and
 @code{AM_DISTCHECK_CONFIGURE_FLAGS} nor by
 @code{DISTCHECK_CONFIGURE_FLAGS}.

-Also note that developers are encouraged to strive to make their code
-buildable without requiring any special configure option; thus, in
-general, you shouldn't define @code{AM_DISTCHECK_CONFIGURE_FLAGS}.
-However, there might be few scenarios in which the use of this variable
-is justified.
-GNU @command{m4} offers an example.  GNU @command{m4} configures by
-default with its experimental and seldom used "changeword" feature
-disabled; so in this case it is useful to have @command{make distcheck}
-run configure with the @option{--with-changeword} option, to ensure that
-the code for changeword support still compiles correctly.
-GNU @command{m4} also employs the @code{AM_DISTCHECK_CONFIGURE_FLAGS}
-variable to stress-test the use of @option{--program-prefix=g}, since at
-one point the @command{m4} build system had a bug where @command{make
-installcheck} was wrongly assuming it could blindly test "@command{m4}",
-rather than the just-installed "@command{gm4}".
+Developers are encouraged to strive to make their code buildable
+without requiring any special configure option; thus, in general, 

bug#67971: [PATCH] Sync shared files from Autoconf

[Karl Berry]

lib/Automake/ChannelDefs.pm and lib/Automake/Channels.pm were updated
in Autoconf to address .

Thanks Zack. Installed.

BTW, the automake THANKS file has your panix.com address. Is that still
ok, or should I update it to owlfolio? (Not that it really matters.) -k

Re: What does (did?) it mean when aclocal exits with code 63?

[Karl Berry]

Hi Zack,

*automake* can exit with code 63 under
some circumstances, but it really looks like aclocal never will.

Agreed. I searched for "63" in automake distributions back to 1.11.3, as
well as the current sources, and no trace of any 63's in aclocal, only
in automake. Thus I suspect that the autoconf test meant to invoke
automake, not aclocal?

Does anyone remember what situation this might have been trying to detect?

"Version mismatch". Of exactly what kind, I don't know :).

The change was made in automake in 2003, according to old/ChangeLog.03.
BTW, I don't see a way that Channels.pm (which aclocal.in uses as of
this change, apparently) exits with code 63, either.

Here are the ChangeLog and NEWS entries. --hope this helps, karl.


2003-09-06  Alexandre Duret-Lutz  

* lib/Automake/XFile.pm: Update to use ChannelDefs.
(close): Call Automake::FileUtils::handle_exec_errors on errors.
* automake.in (scan_autoconf_files): Exit with $?=63 on version
mismatch.
(scan_autoconf_traces): Likewise.  Close the autoconf pipe to
capture abnormal exits.
* aclocal.in ($exit_status): Remove, and use Channels.pm's $exit_code
instead.
(trace_used_macros): Close the autom4te pipe to capture abnormal exits.
* lib/missing: When a tool has run and exited with $?=63, emulate
it.  Adjust the diagnostic and pretend the tool is tool old in this
case.  Use an emacs-updated "scriptversion" variable.
* configure.in: Output tests/aclocal-${APIVERSION} and
tests/automake-${APIVERSION}.
* tests/aclocal.in, tests/automake.in,
tests/missing.test, tests/missing2.test: New files.
* tests/defs.in (AUTOMAKE, ACLOCAL, PATH): Define
to use tests/aclocal-$APIVERSION and tests/automake-$APIVERSION.
* tests/dup3.test: Remove. alocal9.test, acloca10.test, and others are
already testing for this.
* tests/depacl2.test, tests/dup2.test, tests/order.test: Fix
configure.in so that aclocal works.
* tests/defun.test: Quote the AC_DEFUN body.
* tests/Makefile.am (TESTS): Add missing.test and missing2.test,
and remove dup3.test.
(check_SCRIPTS): Add aclocal and automake.

New in 1.8:
..
  - Automake will exit with $? = 63 on version mismatch.  (So does
Autoconf 2.58)  missing knows this, and in this case it will
emulate the tools as if they were absent.  Because older versions
of Automake and Autoconf did not use this exit code, this change
will only be useful in projects generated with future versions of
these tools.

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

[Karl Berry]

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

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

I simply removed the \K, since its only purpose is to optimize use of $&
(matched text), but we aren't using $& with this regexp, so far as I can
discern.  (This line was added for bug#55025, so cc-ing that bug.)

This line with the \K didn't exist in 1.16 (it was added in October
2023), so there may well be something else lurking that makes
"automake --help" fail on Solaris. We'll see.

Now to look into the help2man call in the first place. --thanks, karl.

P.S. We could probably replace all uses of $& with other variables, and
save some small amount of time, as explained in "Performance issues" in
perlvar. I'm not going to go down that road.

bug#67918: random failures with automake-1.16i

[Karl Berry]

Hi Frederic - (switching to bug-automake for tracking)

https://lists.gnu.org/archive/html/automake/2023-12/msg00034.html

I ran `make check` for this release on Fedora-rawhide and got random
failures. Multiple runs seem to show different failures on all arches 

Thanks for the report, and really sorry to hear it. I surmise
subsecond delay problems are back. Automake should fall back when not
using a brand-new (development) autoconf, but apparently this is not
happening. I'll have to investigate further, unless Zack or someone else
gets there first. --thanks, karl.

bug#67894: automake-1.16i pretest available: please test

[Karl Berry]

Hi Peter - thanks for trying the automake pretest.

I get one failure (t/nodef) 

I suspect a timing problem, since I can't fathom any reason why that
particular test would fail on your system specifically.  (The test
basically just runs a minimal automake twice.)

with autoconf 2.71. 

Indeed, since you're not using the development autoconf :),
automake should be falling back to a 1-second delay at various points,
but apparently isn't. I'll have to investigate further.

Please let me know if I can help.

Could you try running the test on its own?
  make VERBOSE=1 check TESTS=t/nodef.sh keep_testdirs=yes

I rather suspect it will succeed. --thanks again, karl.

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

[Karl Berry]

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

Ah. I'll get rid of the \K, once I remember/look up what it does :).
(Jacob, if you have any advice, that would be great.)

A simple fix would be for Automake to require Perl 5.10; 

Nah, we shouldn't require a jump in Perl versions just for this.

I was using the release tarball.

Oh. Seems like that's another (not new, I guess) problem.  help2man
shouldn't be required to build from a tarball, as I understand it.

Thanks,
Karl

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

[Karl Berry]

Hi Paul,

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

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

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

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Karl Berry]

"All possible characters have a UTF-8 representation so this function 
[encode_utf8] cannot fail."

What about non-characters, i.e., byte sequences that are invalid UTF-8?

What I found was that using \N{...} implies a Unicode string. From the
charnames(3) man page (stranged not named "perlcharnames"):

 Otherwise, any string that includes a "\N{charname}" or "\N{U+code
 point}" will automatically have Unicode rules (see "Byte and
 Character Semantics" in perlunicode).

Maybe pack("C") somehow can get to the bytes from a Unicode string?

Sorry I don't have time to experiment more. Must go look at the
first bug reports from the pretest ... --thanks, karl.

automake-1.16i pretest available: please test

[Karl Berry]

We are pleased to announce the GNU Automake 1.16i development snapshot.
We intend for automake 1.17 to be released soon, essentially with only
bug fixes for whatever is found in this pretest. So please do test if at
all possible.

It's our primary goal to preserve compatibility. If this release of
Automake induces failure in a setup that was previously working, please
let us know.

See below for the detailed list of changes since the
previous version, as summarized by the NEWS file.

Download here:

  https://alpha.gnu.org/gnu/automake/automake-1.16i.tar.xz
  https://alpha.gnu.org/gnu/automake/automake-1.16i.tar.gz

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

Thanks to everyone who has reported problems, contributed patches,
and helped test Automake!

With special thanks to Bogdan, Mike Frysinger, Nick Bowler, and 
Zack Weinberg for their numerous contributions.  This release could not
have happened without them.

New volunteers to help maintain Automake are needed. Please help if
you can. For info, see this post (nothing much has changed since):
  https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
and the open bug list:
  https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake



New in (what will be) 1.17:

* New features added

  - AM_PATH_PYTHON will, after checking "python", prefer any Python 3
version (latest versions checked first) over any Python 2
version. If a specific version of Python 2 is still needed, the
$PYTHON variable should be set beforehand.

  - AM_PATH_PYTHON will also search for Python versions 3.15 through 3.10.
It previously searched for 3.9 through 3.0. (bug#53530)

  - RANLIB may be overridden on a per-target basis.

  - AM_TEXI2FLAGS may be defined to pass extra flags to TEXI2DVI & TEXI2PDF.

  - New option "posix" to emit the special target .POSIX for make.

  - Systems with non-POSIX "rm -f" behavior are now supported, and the
prior intent to drop support for them has been reversed.
The ACCEPT_INFERIOR_RM_PROGRAM setting no longer exists.

  - Variables using escaped \# will trigger portability warnings, but be
retained when appended.  GNU Make & BSD Makes are known to support it.
(bug#7610)

  - GNU Make's default pattern rules are disabled, for speed and debugging.
(.SUFFIXES was already cleared.) (bug#64743)

  - For Texinfo documents, if a .texi.in file exists, but no .texi, the
.texi.in will be read. Texinfo source files need not be present at
all, and if present, need not contain @setfilename. Then the file name
as given in the Makefile.am will be used.  If @setfilename is present,
it should be the basename of the Texinfo file, extended with .info.
(bug#54063)

  - The missing script also supports autoreconf, autogen, and perl.

* Bugs fixed

  - Generated file timestamp checks handle filesystems with sub-second
timestamp granularity dynamically, greatly speeding up make check,
etc. However, this requires an autom4te from Autoconf 2.72 (as yet
unreleased) or later (or random test failures and other timing
problems may ensue), as well as a Perl, sleep utility, and
filesystem that supports sub-second resolution; otherwise, we fall
back to one-second granularity as before. When everything necessary
is supported, a new line `Features: subsecond-mtime' is printed by
automake --version (and autom4mte --version). (bug#64756 and bug#67670)

  - The default value of $ARFLAGS is now "cr" instead of "cru", to better
support deterministic builds. (bug#20082)

  - Dependency files are now empty, instead of '# dummy', for speed.

  - Compiling Python modules with Python 3.5+ uses multiple optimization
levels. (bug#38043)

  - When compiling Emacs Lisp files, emacs is run with --no-site-file to
disable user config files that might hang or access the terminal;
and -Q is not used, since its support and behavior varies. (bug#58102)

  - Emacs Lisp compilations respects silent make output.

  - Automake no longer incorrectly warns that the POSIX make variables
$(*D) and the like are non-POSIX. Unfortunately, the make
implementations which do not correctly implement all the POSIX
variables are not detected, but this seems to have little impact
in practice. (bug#9587)

  - Pass libtool tags OBJC and OBJCXX for the respective languages.
(bug#67539)

  - distcleancheck ignores "silly rename" files (.nfs* .smb* .__afs*)
that can show up on network file systems.

  - tests: avoid some declaration conflicts for lex et al. on SunOS.
(bug#34151 and others)

  - Pass any options given to AM_PROG_LEX on to AC_PROG_LEX.
(bug#65600 and bug#65730)

* Miscellaneous changes

* Obsolescence:

  - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
released in 2000, is currently the minimum required 

[bug#67868] intentionally unreadable dirs make distcheck fail

[Karl Berry]

(Sorry, long message.)

As of a few days ago, in a normal working directory, running make
distcheck twice immediately fails the second time (for me):

  if test -d "automake-1.16i"; then find "automake-1.16i" -type d ! -perm -200 
-exec chmod u+w {} ';' && rm -rf "automake-1.16i" || { sleep 5 && rm -rf 
"automake-1.16i"; }; else :; fi
  find: 'automake-1.16i/_build/sub/t/uninstall-fail.dir/__inst-dir__/share': 
Permission denied
  rm: cannot remove 
'automake-1.16i/_build/sub/t/uninstall-fail.dir/__inst-dir__/share': Permission 
denied
  make[2]: *** [Makefile:3266: distdir-am] Error 1

where t/uninstall-fail.dir/__inst-dir__/share is the directory made
intentionally unreadable/unwritable/unsearchable by the uninstall-fail
test, in order to perform its job.

I'm not sure what caused the new failure. Maybe something changing in my
environment (Alma Linux 8), though I don't know what it was. ACL's and
SElinux are not (and never have been) involved, so far as I know.

The failure was apparently because am__remove_distdir only made
unwritable directories writable, but it also seems necessary to make
them readable and searchable. At least, changing distdir.am like this:

+++ b/lib/am/distdir.am
@@ -23,7 +23,7 @@
 
 am__remove_distdir = \
   if test -d "$(distdir)"; then \
-find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
+find "$(distdir)" -type d ! -perm -700 -exec chmod u+rwx {} ';' \

got past that immediate failure on startup. Then make distcheck failed
again, for similar reasons, at the make distcleancheck at the end:

cannot chdir to child for t/uninstall-fail.dir/__inst-dir__/share: 
Permission denied at ../../t/ax/deltree.pl line 29.
cannot remove directory for t/uninstall-fail.dir/__inst-dir__: Directory 
not empty at ../../t/ax/deltree.pl line 29.
cannot remove directory for t/uninstall-fail.dir: Directory not empty at 
../../t/ax/deltree.pl line 29.
make[1]: *** [Makefile:4286: clean-local-check] Error 1
make[1]: Leaving directory '/u/karl/gnu/src/akarl/automake-1.16i/_build/sub'
make: *** [Makefile:3363: distcheck] Error 1

I eventually found that these errors come from the command:
/usr/local/bin/perl ../../t/ax/deltree.pl t/*.dir t/*/*.dir */t/*.dir

which is run as the clean-local-check target (defined in t/local.mk),
which is the dependency of clean-local, which in turn part of the usual
distclean.

Again, I could not see any good reason why this started failing now when
it's been fine for ages. The sub-second patch is an obvious candidate,
as a recent and pervasive change, although the failure is not about
parallelism (surprisingly), since I ran the whole thing without -j, and
the same errors resulted.

Lacking any better insight, I threw in another "fix the horrible mode 0
directories" command before the deltree:

+++ b/t/local.mk
@@ -278,6 +278,7 @@ EXTRA_DIST += $(perf_TESTS)
 clean-local: clean-local-check
 .PHONY: clean-local-check
 clean-local-check:
+   find . -type d ! -perm -700 -exec chmod u+rwx {} ';'
$(AM_V_GEN)$(PERL) $(srcdir)/t/ax/deltree.pl t/*.dir t/*/*.dir */t/*.dir

which made the distclean(check) succeed again.

Furthermore, that mode 0 uninstall-fail.dir/__inst-dir__/share directory
has caused me (at least) quite a bit of unnecessary grief over the
years.  I didn't see any particular reason not to chmod it back to
something reasonable at the end of the test, instead of the whole rest
of the world having to work around the mode 0.  So I made that change too:

+++ b/t/uninstall-fail.sh
@@ -98,4 +98,7 @@ run_make -M -e FAIL uninstall
 
 $EGREP "(cd|sh)(\[[0-9]*[0-9]\])?: .*$inst/share" output
 
+# restore normal permissions so the rest of the world doesn't have to deal.
+chmod u+rwx $inst/share

If anyone has any ideas about what's really going on, and/or if there
are better fixes out there, I'm all ears. Assuming it fails for other
people too, maybe someone smarter than me can run git bisect or
something and discern why the problem started now, at this late date.

Sorry for the horribly verbose explanations of three lines of changes.

At any rate I'm committing the above changes; full patch below. --thanks, karl.

-
dist: more forcefully deal with mode 0 directories created by tests.

* lib/am/distdir.am (am__remove_distdir): make directories
readable and searchable, not just writable. (Also typo.)
* t/local.mk (clean-local-check): ensure directories are
at least mode 700
* t/uninstall-fail.sh: restore reasonable permissions of
the mode 0 $inst/share directory at the end.
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 264713c33..301239de1 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -23,7 +23,7 @@ top_distdir = $(distdir)

 am__remove_distdir = \
   if test -d "$(distdir)"; then \
-find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
+find "$(distdir)" -type d ! -perm -700 -exec chmod u+rwx {} ';' \
  

[bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Karl Berry]

Hi Zack,

Since this touches code shared between Autoconf and Automake, I'm not
checking it in yet and I'm requesting comments from both sides of the
fence.

Well, it seems good to me in principle, FWIW. I don't think this
directly affects automake? I admit I did not try to extract the parts
for automake and run the am tests ... --thanks, karl.

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Karl Berry]

Patch attached.

Looks just fine. Thanks Reuben. I installed it. Closing ...
--all the best, karl.

bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

[Karl Berry]

partially related to how Automake is calling libtool from the 
build rules (it is missing the --tag option), 

I added the tags to automake as previously posted here.
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67539)

no tag defined for Objective C[1] (presumably it would be --tag=OBJC)
...
"If [libtool] can't infer a tag, then it defaults to the
configuration for the C language"
...
lobby for the manual to change rather than rollback the behavior.

I wrote bug-libtool about these things.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67754

Thanks,
Karl

[bug#67670] [PATCH] Revise tests for file mtime resolution again.

[Karl Berry]

In order for the Automake testsuite to be able to use sub-second
delays [...]

I installed the patch (plus a tweak to NEWS). (make check and distcheck
ran fine for me, including using the subsecond feature.)

I included all the commentary from your message, Zack, since I thought
it would likely be helpful to anyone looking at this in the future.

There might be a better place to put this, somewhere
it'll execute every time the *overall testsuite* is invoked
rather than once for each test, but I couldn't find one.

Maybe am__check_pre in lib/am/check.am, where other such things are
done, like handling sh -e, vpath, etc. But I will leave this for another
time.

Thanks Zack. Fingers crossed that this resolves this thorny issue once
and for all ... -k

[bug#67268] [PATCH] texinfo: add pointer about combining tests

[Karl Berry]

I guess I don't see any harm in keeping the link to POSIX. Perhaps it
should be in the Autoconf manual, but either way seems ok to me. Since
the OP went to the trouble of looking it up. --best, karl.

bug#67673: Automake cannot be installed , help will be highly appreciated

[Karl Berry]

Mike wrote me separately to say the problem eventually fixed itself for
no evident reason :(. Maybe related to our general timing issue? 
Anyway, closing. --thanks, karl.

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Karl Berry]

The manual currently says: "You should never explicitly mention the
intermediate (C or C++) file in any `SOURCES' variable; only list
the source file."  

I don't know the code here, and this probably wasn't the question, but I
think the manual's statement about "any `SOURCES' variables" was simply
not meant to apply to BUILT_SOURCES (probably didn't think about it),
but rather to the "normal" something_SOURCES variables. So my gut
reaction is to add "(except @code{BUILT_SOURCES}, see below)".

Later, it talks about adding the header file to
"BUIILT_SOURCES". This seems at odds with what Mike said and I found
empirically.

I suggest that we could just say to add both files, although if you want
to try to understand what's actually going on, more power to you :).

Best,
Karl

bug#67673: Automake cannot be installed , help will be highly appreciated

[Karl Berry]

nobase-python: running python -V
Python 3.12.0
...
ModuleNotFoundError: No module named 'imp'

Looks like the failing tests are all Python-related, at least several
with the above error. I don't think Python 3.12 was even released at the
time of automake 1.16.5. I don't know what exactly is going wrong, but
there has been quite a bit of work on the Python support for the next
release.

If you don't need Python support, you can just ignore the failing tests
and go ahead and install automake anyway.

If you do need Python support, I can only suggest trying the
development source. I hope we will have at least a pretest ready soon,
but nothing is available yet.
https://savannah.gnu.org/projects/automake/

Hope this helps,
Karl