bug#68274: automake 1.16j nonnumerical version confuses scripts

[Mike Frysinger]

On 21 Jan 2024 14:42, Karl Berry wrote:
> I changed the pretest version to 1.16.90. Closing.

thx bud.  i appreciates you.
-mike


signature.asc
Description: PGP signature

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

[Mike Frysinger]

On 17 Jan 2024 00:11, Mike Frysinger wrote:
> On 15 Feb 2022 23:03, Damian Szuberski wrote:
> > A standard `libtool` invocation line generated by automake looks like:
> > ```
> > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> > $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> > $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> > $(AM_CFLAGS) $(CFLAGS)
> > ```
> > Sometimes files compiled using the method above make the compiler emit
> > errors. Those errors are suppressed by default which makes troubleshooting
> > impossible. `libtool` has a command line option, `-no-suppress` which can
> > be used to make the compiler verbose. Unfortunately, there is no way to
> > inject that option since `libtool` demands that it comes after
> > `--mode=compile`. `AM_LIBTOOLFLAGS` nor `LIBTOOLFLAGS` cannot be used for
> > that purpose since "it is too early", according to `libtool`'s command line
> > parser. It is somewhat possible to use `AM_CFLAGS` for that purpose but
> > then it breaks modes other than `--mode=compile`.
> 
> i was reading the libtool manual today and was reminded that libtool processes
> some standard options straight out of the wrapped command rather than forcing
> you to split things up.  for example, it detects the -o option and parses 
> that.
> then i was reminded that when passing libtool linker options like 
> -no-undefined,
> you simply add them to the standard LDFLAGS.
> 
> which is to say, options like -no-suppress do not need exact placement.  put 
> it
> in existing CFLAGS variables as makes sense for your target.
>   AM_CFLAGS = -no-suppress
> or
>   libfoo_la_CFLAGS = $(AM_CFLAGS) -no-suppress
> and libtool should parse & discard it before invoking the underlying compiler.

the Automake manual has libtool examples for general & linking flags,
but nothing for compiling.  we could add some to make it more clear.
-mike


signature.asc
Description: PGP signature

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

[Mike Frysinger]

On 15 Feb 2022 23:03, Damian Szuberski wrote:
> A standard `libtool` invocation line generated by automake looks like:
> ```
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CFLAGS) $(CFLAGS)
> ```
> Sometimes files compiled using the method above make the compiler emit
> errors. Those errors are suppressed by default which makes troubleshooting
> impossible. `libtool` has a command line option, `-no-suppress` which can
> be used to make the compiler verbose. Unfortunately, there is no way to
> inject that option since `libtool` demands that it comes after
> `--mode=compile`. `AM_LIBTOOLFLAGS` nor `LIBTOOLFLAGS` cannot be used for
> that purpose since "it is too early", according to `libtool`'s command line
> parser. It is somewhat possible to use `AM_CFLAGS` for that purpose but
> then it breaks modes other than `--mode=compile`.

i was reading the libtool manual today and was reminded that libtool processes
some standard options straight out of the wrapped command rather than forcing
you to split things up.  for example, it detects the -o option and parses that.
then i was reminded that when passing libtool linker options like -no-undefined,
you simply add them to the standard LDFLAGS.

which is to say, options like -no-suppress do not need exact placement.  put it
in existing CFLAGS variables as makes sense for your target.
AM_CFLAGS = -no-suppress
or
libfoo_la_CFLAGS = $(AM_CFLAGS) -no-suppress
and libtool should parse & discard it before invoking the underlying compiler.

for example:
$ echo 'main(){}' > test.c
$ libtool --tag=CC --mode=compile gcc -c -Wall test.c -no-suppress
libtool: compile:  gcc -c -Wall -Wextra test.c  -fPIC -DPIC -o .libs/test.o
test.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | main(){}
  | ^~~~
libtool: compile:  gcc -c -Wall -Wextra test.c -o test.o
test.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | main(){}
  | ^~~~
-mike


signature.asc
Description: PGP signature

bug#54020: Allow user-defined libtool options

[Mike Frysinger]

On 16 Jan 2024 22:43, Roumen Petrov wrote:
> Mike Frysinger wrote:
> > On 13 Jan 2024 22:29, Bogdan wrote:
> >> Mike Frysinger , 2024-01-13 07:19:
> >>> On 15 Mar 2023 17:31, Bogdan wrote:
> >>>> Another patch from my side. This one makes it possible for users to
> >>>> pass additional options to libtool in 'compile' mode. Fixes #54020.
> >>>>
> [SNIP]
> 
> Libtool support options that allows user to pass flags either or compiler or 
> linker.
> I cannot see needs for more flags and variables.

sorry, but i'm not following what you're trying to say here
-mike


signature.asc
Description: PGP signature

bug#54020: Allow user-defined libtool options

[Mike Frysinger]

On 14 Jan 2024 18:55, Bogdan wrote:
> Mike Frysinger , 2024-01-14 02:06:
> > On 13 Jan 2024 22:29, Bogdan wrote:
> >> Mike Frysinger , 2024-01-13 07:19:
> >>> On 15 Mar 2023 17:31, Bogdan wrote:
> >>>> Another patch from my side. This one makes it possible for users to
> >>>> pass additional options to libtool in 'compile' mode. Fixes #54020.
> >>>>
> >>>> Added documentation and a test case including the '-no-suppress'
> >>>> option. All tests with 'lt' or 'libtool' in the name pass.
> >>>>
> >>>> Feel free to rename the variables, I just came up with the names
> >>>> LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
> >>>> where the variables are put and the mode they're used in.
> >>>
> >>> why do we need LTCOMPILE_POSTFLAGS ?  isn't that just after the compile
> >>> command ?  $obj_compile expands into e.g.
> >>>   \$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
> >>>
> >>> so if someone wants to add flags to C/etc..., they already have knobs
> >>> to turn.
> >>>
> >>> which means this would simplify by only having one variable right ?
> >>> AM_LTCOMPILE_FLAGS
> >>
> >>Seems so, at least for now. At least for C compilers. At least until
> >> $obj_compile becomes something else in the future or something more,
> >> or even now contains (or will contain) other options after $(CFLAGS)
> >> on the command line when using other compilers.
> >>For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
> >> suffice, at least now, as it seems. I've made pre- and post- flags for
> >> better flexibility, to be future-proof.
> >
> > i don't see there ever being a future need here.  libtool's design is that
> > it stops processing after the first non-argument after --mode=compile, and
> > everything else is a wrapped command which libtool blindly executes.  those
> > commands should have their own set of flags, and libtool is irrelevant at
> > that point, so giving it a libtool-centric name that is used regardless of
> > the wrapped command will never make sense.
> 
>   And that's probably something I wasn't aware of. If it's
> dead/useless code, feel free to remove this part. The fact that I made
> a patch doesn't mean that it must be applied as a whole and never changed.

the point of posting patches for review is to review and discuss and learn.
maybe you saw something or an angle that i missed.  i don't know everything.
-mike


signature.asc
Description: PGP signature

bug#68274: automake 1.16j nonnumerical version confuses scripts

[Mike Frysinger]

On 13 Jan 2024 15:58, Karl Berry wrote:
> 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.

using .90 is certainly better than single-letters.  if you're fine with
it, then let's switch.

i cut more inline responses to avoid further bikeshedding on the topic.
we can agree to disagree.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 13 Jan 2024 19:12, Karl Berry wrote:
> 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.

yeah, it sucks.  i'm on the fence whether we should have python support in
automake at all tbh.

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

i assume you're being facetious here -- i think the Python folks learned
their lesson with 2->3 and won't do another major bump.
-mike


signature.asc
Description: PGP signature

bug#54020: Allow user-defined libtool options

[Mike Frysinger]

On 13 Jan 2024 22:29, Bogdan wrote:
> Mike Frysinger , 2024-01-13 07:19:
> > On 15 Mar 2023 17:31, Bogdan wrote:
> >>Another patch from my side. This one makes it possible for users to
> >> pass additional options to libtool in 'compile' mode. Fixes #54020.
> >>
> >>Added documentation and a test case including the '-no-suppress'
> >> option. All tests with 'lt' or 'libtool' in the name pass.
> >>
> >>Feel free to rename the variables, I just came up with the names
> >> LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
> >> where the variables are put and the mode they're used in.
> >
> > why do we need LTCOMPILE_POSTFLAGS ?  isn't that just after the compile
> > command ?  $obj_compile expands into e.g.
> > \$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
> >
> > so if someone wants to add flags to C/etc..., they already have knobs
> > to turn.
> >
> > which means this would simplify by only having one variable right ?
> > AM_LTCOMPILE_FLAGS
> 
>   Seems so, at least for now. At least for C compilers. At least until
> $obj_compile becomes something else in the future or something more,
> or even now contains (or will contain) other options after $(CFLAGS)
> on the command line when using other compilers.
>   For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
> suffice, at least now, as it seems. I've made pre- and post- flags for
> better flexibility, to be future-proof.

i don't see there ever being a future need here.  libtool's design is that
it stops processing after the first non-argument after --mode=compile, and
everything else is a wrapped command which libtool blindly executes.  those
commands should have their own set of flags, and libtool is irrelevant at
that point, so giving it a libtool-centric name that is used regardless of
the wrapped command will never make sense.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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.

* m4/python.m4: Add python3.20 - python3.16.
* NEWS: Mention new Python versions.
---
 NEWS | 2 +-
 m4/python.m4 | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index c4e3d58ecb27..c53573a0abbb 100644
--- a/NEWS
+++ b/NEWS
@@ -12,7 +12,7 @@ New in 1.17:
 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.
+  - AM_PATH_PYTHON will also search for Python versions 3.20 through 3.10.
 It previously searched for 3.9 through 3.0. (bug#53530)
 
   - RANLIB may be overridden on a per-target basis.
diff --git a/m4/python.m4 b/m4/python.m4
index 8d4e4d21585b..2de57c52ae81 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -38,6 +38,7 @@ AC_DEFUN([AM_PATH_PYTHON],
   dnl supported. (2.0 was released on October 16, 2000).
   m4_define_default([_AM_PYTHON_INTERPRETER_LIST],
 [python python3 dnl
+ python3.20 python3.19 python3.18 python3.17 python3.16 dnl
  python3.15 python3.14 python3.13 python3.12 python3.11 python3.10 dnl
  python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3 dnl
  python3.2 python3.1 python3.0 dnl
-- 
2.43.0

Re: [question] how to install a directory to pythondir?

[Mike Frysinger]

On 06 Apr 2023 02:34, Wu Zhenyu wrote:
> https://www.gnu.org/software/automake/manual/html_node/Python.html
> describe how to package python by automake. I have
> 
> $ tree src/foobar
>  src/foobar
> ├──  __init__.py
> ├──  __main__.py
> └──  utils
>├──  a.py
>├──  b.py
>└──  c.py
> 
> And my Makefile.am contains
> 
> python_PYTHON = src/foobar

i think there might be a philosophical mismatch here.  Automake doesn't
take arbitrary dirs as inputs, much like it doesn't accept wildcards.
it wants every file that it's responsible for to be enumerated.  this
avoids things like `cp src/foobar/__init__.py src/foobar/todo-backup.py`
and then having todo-backup.py automatically get sucked up into release
tarballs.

what about src/foobar/.test.py ?  should we include that too ?
what about src/foobar/__init__.py~ ?  should we include that too ?

the practical result is that the build code gets a bit verbose ...

> If I
> 
> python_PYTHON = src/foobar/__init__.py src/foobar/__main__.py  
> src/foobar/utils/a.py src/foobar/utils/b.py src/foobar/utils/c.py
> 
> I got
> 
> $ ls /tmp/abc/lib/python3.10/site-packages
> __init__.py __main__.py a.py b.py c.py
> 
> I expected
> 
> $ ls /tmp/abc/lib/python3.10/site-packages
> foobar
> $ ls /tmp/abc/lib/python3.10/site-packages/foobar
> __init__.py __main__.py utils/
> $ ls /tmp/abc/lib/python3.10/site-packages/foobar/utils
> a.py b.py c.py
> 
> So, how to install a directory to pythondir?

i would guess something like (untested):

python_foobardir = $(pythondir)/foobar
python_foobar_PYTHON = src/foobar/__init__.py src/foobar/__main__.py
python_foobar_utilsdir = $(python_foobardir)/utils
python_foobar_utils_PYTHON = src/foobar/utils/a.py src/foobar/utils/b.py 
src/foobar/utils/c.py

prob want to write a script to automatically generate this boilerplate
for your project so you don't have to manually keep it up-to-date ...
-mike


signature.asc
Description: PGP signature

bug#8362: make install prefix inserted in source code with generated python files

[Mike Frysinger]

On 21 Mar 2023 23:05, Bogdan wrote:
>   Third, and most important (I think) is that we need to note that 
> "prog/x.py" is GENERATED, but is NOT marked so. Adding
> 
>   BUILT_SOURCES = prog/x.py

i don't think this is a correct use of BUILT_SOURCES.
https://www.gnu.org/software/automake/manual/automake.html#Sources

that var is meant for generating headers before Automake's depgen logic
can kick in.  that sounds minor, but in practice it means that every
built source is generated before anything else is compiled.  which can
insert a bubble into parallel build pipelines.  so we would prefer it
only be used for things that matter to header dependency generation.
-mike


signature.asc
Description: PGP signature

bug#54020: Allow user-defined libtool options

[Mike Frysinger]

On 15 Mar 2023 17:31, Bogdan wrote:
>   Another patch from my side. This one makes it possible for users to 
> pass additional options to libtool in 'compile' mode. Fixes #54020.
> 
>   Added documentation and a test case including the '-no-suppress' 
> option. All tests with 'lt' or 'libtool' in the name pass.
> 
>   Feel free to rename the variables, I just came up with the names 
> LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions 
> where the variables are put and the mode they're used in.

why do we need LTCOMPILE_POSTFLAGS ?  isn't that just after the compile
command ?  $obj_compile expands into e.g.
\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)

so if someone wants to add flags to C/etc..., they already have knobs
to turn.

which means this would simplify by only having one variable right ?
AM_LTCOMPILE_FLAGS
-mike


signature.asc
Description: PGP signature

Re: propably automake bug

[Mike Frysinger]

i think you might be describing this bug report:
https://debbugs.gnu.org/60508
-mike


signature.asc
Description: PGP signature

bug#62069: Support xz parallel compression in dist-xz

[Mike Frysinger]

On 09 Mar 2023 08:47, Sam James wrote:
> xz supports parallel compression which obviously speeds up
> the time taken to run the 'dist-xz' rule, but it also
> speeds up *decompression* too, as the parallel compressor
> creates different output which can be decompressed in parallel.
> 
> There's two options, I think, for automake:
> 1. Pass -T+1 to xz if xz is >= 5.4.0 (a runtime check
> would be needed, but it's cheap to do) as this uses
> 1 thread, but uses the parallel compressor to do it,
> so allows decompression in parallel by users;
> 
> 2. Pass -T0 (or -Tn, n >= 1) to allow autodetection
> of the number of available CPU cores (or n if specified)
> which also then naturally uses the threaded compressor.

it should be a configure check when dist-xz is enabled in the call to
AM_INIT_AUTOMAKE, and we should default to `-T0`.  this would be the
default XZ_OPT value if it hasn't been set/overridden (where we use
-e now).
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 28 May 2022 12:14, Jim Meyering wrote:
> A few days ago I was preparing to release grep and wanted to make sure
> it'd work with the latest automake and autoconf, so I built and installed
> each from master. That exposed these errors when bootstrapping grep. I
> think it was a prerequisite to have run grep's "make maintainer-clean":
> 
>   configure.ac:41: warning: _AM_PROG_RM_F is m4_require'd but not\
> m4_defun'd
>   configure.ac:41: warning: _AM_PROG_XARGS_N is m4_require'd but not\
> m4_defun'd
>   configure:5058: error: possibly undefined macro: _AM_PROG_RM_F
>   configure:5059: error: possibly undefined macro: _AM_PROG_XARGS_N
> 
> I've just pushed the attached fix.
> Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7
> so this doesn't need a NEWS update.
> 
> Mike, can you add an automake test that would have caught this?

does `make distcheck` not catch this ?  would be nice if we could catch
with a git checkout directly, but seems difficult to pull off.

would it be reasonable to assume that every m4/*.m4 file is supposed
to be installed ?  that wouldn't be too hard to run tests against,
but it would make things a little more tricky for devs working out
of the git tree with uncommitted local changes.

the problem with running $ACLOCAL is that it's configured to search
the local ../m4/ tree for all macros that exist ...

is there some m4 invocation we could run that would scan all the
installed m4 files ?  we can pass down the known list of m4 files to
be installed, but how to actually scan/validate them i'm not sure.
-mike


signature.asc
Description: PGP signature

bug#68274: automake 1.16j nonnumerical version confuses scripts

[Mike Frysinger]

On 06 Jan 2024 15:37, Karl Berry wrote:
> Automake and other packages have used letters for pretests for decades,

true ...

> and it's not plausible to change now.

eh ?  there is nothing requiring or restricting the current version behavior
other than "it's always been this way".  but that doesn't mean it's better.

there's no reason we couldn't use more modern convention here like -rc#.
appending a letter at the end to indicate a *pre*release is extremely
uncommon nowadays.

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

some do, but they use separators which makes it easier to split+compare.
if they smashed it together, it'd be impossible to determine where the
version stopped and where the git sha started.

e.g. 1.2.3-gab989de
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 02 Dec 2023 21:55, Paul Eggert wrote:
> -if test -z "$PERL"; then
> +case $PERL in

AS_CASE ?
-mike


signature.asc
Description: PGP signature

bug#62791: BUILT_SOURCES not honoured in parallel build?

[Mike Frysinger]

On 12 Apr 2023 18:14, Reuben Thomas via Bug reports for Automake wrote:
> On Wed, 12 Apr 2023 at 17:59, Reuben Thomas  wrote:
> > On Wed, 12 Apr 2023 at 16:17, Reuben Thomas  wrote:
> >
> >> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
> >> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
> >> sometimes:
> >
> > In fact, I don't need to do a parallel build, just build serially from a
> > fresh git checkout, to reproduce this problem. It seems that I must be
> > doing something wrong, but I can't work out what!
> 
> I think I've worked it out: I need to add the .c file that is generated
> from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing that
> fixes the problem.

we prob could add a .y/.l example to the manual.  i think i tripped over this
error myself in a project in the past.  i think you want to list both files.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 30 Nov 2023 22:45, Nick Bowler wrote:
> Interestingly the libtool manual also says "If [libtool] can't infer a 
> tag, then it defaults to the configuration for the C language", which is 
> clearly not the case (it seems what actually happens is that if libtool 
> can't infer a tag then it exits with a fatal error).  So I wonder if
> this is actually a regression in libtool.

i'm fairly certain libtool used to do this aages ago, and i *think*
it stopping was intentional.  i recall a lot of pain in Gentoo from that
switchup, but tbh, i don't think any of it was "wrong" ... all the fixes we
landed were because the code was being misused/abused, and silently doing
the wrong thing (especially when cross-compiling).  so i personally prefer
the new world order, and would say we should lobby for the manual to change
rather than rollback the behavior.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 02 Dec 2023 15:53, Karl Berry wrote:
> also, can we really not trust the exit status of grep ?
> if echo "$PERL" | grep -q '[\t ]'; then
> 
> Exit status yes, but at least historically, grep -q has been considered
> non-portable, in favor of grep ... >/dev/null.

i get that `grep -q` is something historically we've avoided, but i think it's
one of those bad habits we should just get out of.  i'll note that gnuconfig
uses `grep -q` in a bunch of places.

not that i'm going to spend time going through the codebase to update all the
usage, so if automake itself currently does it this way, OK.

> I committed the change as below. --thanks, karl.

thanks, lgtm
-mike


signature.asc
Description: PGP signature

[bug#67498] Fixes for Windows

[Mike Frysinger]

On 27 Nov 2023 14:35, Karl Berry wrote:
> https://savannah.gnu.org/patch/?10417
> 
> Unfortunately, last I heard, the new libtool maintainer was AWOL and no
> one is left actively maintaining it. Or even looking for a maintainer. A
> sad state of affairs :(. --best, karl.

i've always been curious as to how libtool works.  if you're referring to
Alex Ameen, it was surprising that he was the new maintainer when he never
seemed to have done anything in libtool, or any other autotools project,
before he was suddenly the main (only?) maintainer.
-mike


signature.asc
Description: PGP signature

Re: rhel8 test failure confirmation?

[Mike Frysinger]

On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> >> Karl Berry wrote:
> >>> jb> a more thorough test would locate the autom4te script and grep it
> >>> for the perllibdir that was substituted when autoconf was
> >>> configured.
> >>>
> >>> I guess that would work.
> >>>   
> >> Challenge accepted.  Here's a refined version:  (lines \-folded for email)
> >>
> >> if $PERL -I${autom4te_perllibdir:-$(sed -n \
> >>   '/autom4te_perllibdir/{s/^.*|| //;s/;$//;s/^.//;s/.$//;p;q}' 
> >> \
> >> <$(command -v autom4te))} -MAutom4te::FileUtils \
> >>  -e 'exit defined $INC{q[Time/HiRes.pm]} ? 0 : 1'; then
> >># autom4te uses Time::HiRes
> >> else
> >># autom4te does not use Time::HiRes
> >> fi
> >> 
> >
> > this doesn't work on systems that wrap `autom4te`.  Gentoo for example wraps
> > all autoconf & automake scripts to support parallel installs of different
> > versions.  this way we can easily have access to every autoconf version.  we
> > got this idea from Mandrake, so we aren't the only ones ;).
> 
> If you install a wrapper script, (instead of, for example, making 
> autom4te, etc. easily-repointable symlinks), then you must also set 

symlinks are vastly inferior.  they require privilege to modify, are not atomic,
and bleed into the rest of the system and other users.  the wrappers we have in
Gentoo on the otherhand respect env vars (so you can e.g. WANT_AUTOCONF=2.53),
and by default scan the current set of generated files to see what was used, and
then see what's installed to automatically match.  so if you're running automake
in a project built with automake 1.11 and you have that installed, we will use
it automatically for you.  or you can force WANT_AUTOMAKE=latest to always use
the latest version.

> autom4te_perllibdir in the environment to the appropriate directory when 
> building autoconf/automake.  This (with the Gentoo-specific knowledge of 
> where the active autom4te is actually located) should be easy to add to 
> the ebuild.
> 
> If autom4te_perllibdir is set in the environment, its value will be used 
> instead of extracting that information from the autom4te script.

when e.g. autoconf 2.69 is built to use versioned paths at configure, compile,
and install time, there is no need to muck around with internal vars like the
autom4te_perllibdir.  `autoconf-2.69` & `autom4te-2.69` always invokes exactly
the 2.69 version regardless of what `autoconf` does.

so i don't know why we would need to set/export autom4te_perllibdir in our
wrapper.  we've been doing this for over 20 years without ever setting that
var (or any other internal autoconf/automake var), so i'm pretty confident
our approach is OK.

> > seems like the only reliable option is to invoke autom4te.
> > am_autom4te_ver=`$AUTOM4TE --version | sed -n '1{s:.*) ::;p}'
> > AS_CASE([$am_autom4te_ver],
> > ... do the matching ...
> >
> > what is the first autoconf release that has the fix ?
> 
> The problem with testing autoconf versions for this is that Time::HiRes 
> is an *optional* module in Perl.  It was available from CPAN before it 
> was bundled with Perl, and distributions technically can *unbundle* it 
> from later Perl releases if they want.  The only reliable way to know if 
> Time::HiRes is available (without effectively reimplementing Perl's 
> module search) is to try to load it.  Autom4te now (correctly) uses 
> Time::HiRes if it is available and falls back to Perl builtins if not, 
> for any version of Perl.  The best way to check if high-resolution 
> timestamps are available to autom4te is to have perl load 
> Autom4te::FileUtils and check if that also loaded Time::HiRes.

i'm not aware of anything loading the Autom4te perl modules outside of the
autoconf projects.  does that actually happen ?  i don't think we want to
have automake start loading autoconf perl modules directly.  going through
the CLI interface seems better at this point.
-mike


signature.asc
Description: PGP signature

Re: rhel8 test failure confirmation?

[Mike Frysinger]

On 02 Dec 2023 18:33, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
> > On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> >> The best way to check if high-resolution 
> >> timestamps are available to autom4te is to have perl load 
> >> Autom4te::FileUtils and check if that also loaded Time::HiRes.
> >>
> >> The problem with that turned out to be that Time::HiRes got loaded from
> >> other system modules, resulting in the test thinking that autom4te used
> >> it when that wasn't actually the case. That's what happened in practice
> >> with your patch.
> >
> > Would it help if we added a command line option to autom4te that made it 
> > report whether it thought it could use high resolution timestamps? Versions 
> > of autom4te that didn't recognize this option should be conservatively 
> > assumed not to support them.
> 
> Why not just add that information to the --version message?  Add a 
> "(HiRes)" tag somewhere if Time::HiRes is available?  All versions that 
> know to check if Time::HiRes is loaded will also know how to use it, 
> unlike the earlier test.

parsing out the exact version from --version is already a pita.  trying it
freeform text that we also want tools to do substring searching on sounds
extremely fragile and the opposite of future-proof.

libtool at least has a --config option that dumps shell-link syntax.
-mike


signature.asc
Description: PGP signature

Re: rhel8 test failure confirmation?

[Mike Frysinger]

On 02 Dec 2023 19:17, Zack Weinberg wrote:
> On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> > The best way to check if high-resolution 
> > timestamps are available to autom4te is to have perl load 
> > Autom4te::FileUtils and check if that also loaded Time::HiRes.
> >
> > The problem with that turned out to be that Time::HiRes got loaded from
> > other system modules, resulting in the test thinking that autom4te used
> > it when that wasn't actually the case. That's what happened in practice
> > with your patch.
> 
> Would it help if we added a command line option to autom4te that made it 
> report whether it thought it could use high resolution timestamps? Versions 
> of autom4te that didn't recognize this option should be conservatively 
> assumed not to support them.

upthread somewhere Karl (iirc) threw out a bikeshed idea like --has=.
i don't know if any of the autotools or GNU tools have such things that we
could duplicate to avoid bikeshedding too much.  that would make it work in
this case easily, and setup framework for future checks.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 02 Dec 2023 15:09, Karl Berry wrote:
> very extensive "Portable Shell Programming" chapter:
> 
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Portable-Shell.html
> 
> I know. The Autoconf manual already describes this issue in detail.
> The point of the brief mention in the Automake manual is because it is
> precisely the place and the problem that are rather likely to come up
> in practice.
> 
> I see I failed to link to the Autoconf node, though. I'll add that. -k

breadcrumbs in the automake manual is ok before tossing them to autoconf, but i
would make it more brief than we have now.  like drop references to the POSIX
state and just leave it as discouraged in favor of the macros for portability.
-mike


signature.asc
Description: PGP signature

Re: rhel8 test failure confirmation?

[Mike Frysinger]

On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> Karl Berry wrote:
> > jb> a more thorough test would locate the autom4te script and grep it
> > for the perllibdir that was substituted when autoconf was
> > configured.
> >
> > I guess that would work.
> 
> Challenge accepted.  Here's a refined version:  (lines \-folded for email)
> 
> if $PERL -I${autom4te_perllibdir:-$(sed -n \
>   '/autom4te_perllibdir/{s/^.*|| //;s/;$//;s/^.//;s/.$//;p;q}' \
> <$(command -v autom4te))} -MAutom4te::FileUtils \
>  -e 'exit defined $INC{q[Time/HiRes.pm]} ? 0 : 1'; then
># autom4te uses Time::HiRes
> else
># autom4te does not use Time::HiRes
> fi

this doesn't work on systems that wrap `autom4te`.  Gentoo for example wraps
all autoconf & automake scripts to support parallel installs of different
versions.  this way we can easily have access to every autoconf version.  we
got this idea from Mandrake, so we aren't the only ones ;).

as such, running git configure produces errors:
checking for autom4te... /usr/bin/autom4te
grep: /Autom4te/FileUtils.pm: No such file or directory
checking the filesystem timestamp resolution... 2

and then breaks some tests:
$ grep ^FAIL: test-suite.log 
FAIL: t/depcomp2
FAIL: t/distcheck-no-prefix-or-srcdir-override

t/depcomp2.log showing:
+ cat stderr
grep: /Autom4te/FileUtils.pm: No such file or directory
+ sed /rm:.*conftest\.dSYM/d stderr
+ test -s stderr2
+ cat stderr2
grep: /Autom4te/FileUtils.pm: No such file or directory
+ _am_exit 1

seems like the only reliable option is to invoke autom4te.
am_autom4te_ver=`$AUTOM4TE --version | sed -n '1{s:.*) ::;p}'
AS_CASE([$am_autom4te_ver],
... do the matching ...

what is the first autoconf release that has the fix ?
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 27 May 2023 19:12, Karl Berry wrote:
> I (finally) installed this patch to quit early if the perl path has
> spaces. Thanks.
> 
> As for MKDIR_P and INSTALL, I guess it is somewhere in the
> prerequisite/autoconf stuff. I suppose it would be rare that they would
> be found in a path with spaces while perl was not, so I think it's ok to
> let that go. --best, karl.
> 
> --- a/configure.ac
> +++ b/configure.ac
> @@ -71,6 +71,12 @@ AC_PATH_PROG([PERL], [perl])
>  if test -z "$PERL"; then
> AC_MSG_ERROR([perl not found])
>  fi
> +if test x"`echo $PERL | grep ' '`" != "x"; then

this is expanding $PERL unquoted and letting the shell normalize the whitespace
by passing the resulting args to echo.  how strict do we need to be with this ?
for example, this will let some pathological values pass that shouldn't.
$ PERL="   /usr/bin/perl   "
$ echo $PERL | grep ' '; echo $?
1
the advantage of the check as-written is that it normalizes all whitespace (e.g.
tabs) into just spaces which we can grep on.  i'm assuming we can't rely on
`[:space:]` and such.  but maybe including that is portable enough ?
echo "$PERL" | grep '[ \t]'

also, can we really not trust the exit status of grep ?
if echo "$PERL" | grep -q '[\t ]'; then
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 18 Nov 2023 19:27, Karl Berry wrote:
> Hi Michael,
> 
> 
> Date: Sun, 16 Oct 2016 18:35:53 +0200
> From: Michael Stapelberg 
> To: automake-patches@gnu.org
> Subject: [PATCH] texinfo: add pointer about combining tests
> 
> https://lists.gnu.org/archive/html/automake-patches/2016-10/msg2.html
> 
> Seven years late(r), but I did finally merge (a version of) your
> suggestion of a portability note in the Automake manual about &&
> vs. test -a, as below.  Thanks! --karl
> 
> 
> doc: mention shell operators preferred over `test` options.

is the automake manual the best place for this ?  the autoconf manual has a
very extensive "Portable Shell Programming" chapter:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Portable-Shell.html

seems like it'd be better to extend that section and link it from here.
-mike


signature.asc
Description: PGP signature

Re: Getting long SOURCES lines with subdirs shorter

[Mike Frysinger]

On 01 Dec 2023 17:39, Nick Bowler wrote:
> On 2023-12-01 15:37, Jan Engelhardt wrote:
> > On Friday 2023-12-01 21:13, Mike Frysinger wrote:
> >> On 17 Jul 2023 16:51, Karl Berry wrote:
> >>> Hi Jan,
> >>>
> >>> Current automake likely won't have anything in store already,
> >>>
> >>> Not that I know of.
> >>>
> >>> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
> >>>
> >>> I've often wanted this myself. I'd certainly welcome a patch for it.
> >>>
> >>> Please work from automake trunk. None of the various branches are kept
> >>> to date. (Sad but that's the reality.)
> >>
> >> prob stating the obvious, but $(addprefix) is a GNUism, so if we wanted to
> >> use it, it'd required feature probing at configure time, and that always
> >> complicates things :(
> > 
> > No-no, the idea was to make $(addprefix) an automakeism that is resolved 
> > before
> > GNU make (or any other make) is ever invoked.
> 
> I suggest inventing a new syntax if this approach is taken, one that
> doesn't overload real-world make syntax, since some people do use
> Automake with GNU-make-specific rules and whatnot.  We already have
> things like %reldir% which are expanded by Automake so maybe using
> percent signs as a marker for "things expanded by automake" would
> be a good starting point for this.
> 
> I do sometimes wish Automake had more built-in macro facilities.
> One can do things like generate includeable snippets or preprocess
> Makefile.am with, say, m4, but that adds a bunch of additional
> complexity which is not always worthwhile.

we're already blurring the lines by processing things like `if`.
it also has the benefit of not having to learn more automake-only
DSLs like the %var% syntax.  imo it's ok to preprocess things that
can be statically done like $(addprefix).
-mike


signature.asc
Description: PGP signature

Re: Getting long SOURCES lines with subdirs shorter

[Mike Frysinger]

On 01 Dec 2023 21:37, Jan Engelhardt wrote:
> On Friday 2023-12-01 21:13, Mike Frysinger wrote:
> >On 17 Jul 2023 16:51, Karl Berry wrote:
> >> Hi Jan,
> >> 
> >> Current automake likely won't have anything in store already,
> >> 
> >> Not that I know of.
> >> 
> >> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
> >> 
> >> I've often wanted this myself. I'd certainly welcome a patch for it.
> >> 
> >> Please work from automake trunk. None of the various branches are kept
> >> to date. (Sad but that's the reality.)
> >
> >prob stating the obvious, but $(addprefix) is a GNUism, so if we wanted to
> >use it, it'd required feature probing at configure time, and that always
> >complicates things :(
> 
> No-no, the idea was to make $(addprefix) an automakeism that is resolved 
> before
> GNU make (or any other make) is ever invoked.

i thought your concern was about Makefile.in noise.  Makefile.am is somewhat
mitigated via modules & %D%/ prefixes already.  not that i'm anti expanding
things statically when feasible.
-mike


signature.asc
Description: PGP signature

[bug#67516] [PATCH] aclocal: handle both # and dnl for serial number lines

[Mike Frysinger]

On 01 Dec 2023 16:10, Karl Berry wrote:
> without realizing it's basically silently ignored.  if we don't want
> to support dnl, we should prob be chatty about it at some log level.
> 
> The "Serials" node in the manual only mentions "#". I guess I don't see
> a need to go out of our way to do anything else, given that this was the
> only report about it (and the OP's email now bounces). --thanks, karl.

i tend to see it as "if one person took the time to track us down and
complain, then chances are there's more who didn't".  which means some
people tried dnl, noticed, fought the system, then figured it out.  imo
if the diagnostics are easy & cheap to add, then saving a few people a
bit of pain is nice, especially when it's a common practice we adopt,
and not just this one thing in isolation.

all that said, i'm not interested in writing the patch for this particular
issue, especially when manual serial management is uncommon, and i rarely
do it myself.
-mike


signature.asc
Description: PGP signature

Re: Getting long SOURCES lines with subdirs shorter

[Mike Frysinger]

On 17 Jul 2023 16:51, Karl Berry wrote:
> Hi Jan,
> 
> Current automake likely won't have anything in store already,
> 
> Not that I know of.
> 
> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
> 
> I've often wanted this myself. I'd certainly welcome a patch for it.
> 
> Please work from automake trunk. None of the various branches are kept
> to date. (Sad but that's the reality.)

prob stating the obvious, but $(addprefix) is a GNUism, so if we wanted to
use it, it'd required feature probing at configure time, and that always
complicates things :(
-mike


signature.asc
Description: PGP signature

[bug#67516] [PATCH] aclocal: handle both # and dnl for serial number lines

[Mike Frysinger]

On 28 Nov 2023 16:27, Nick Bowler wrote:
> On 2023-11-28 16:06, Karl Berry wrote:
> > Hi Ross - you sent a change to automake-patches back in February 2017.
> > Sorry for the absurdly delayed reply.
> > 
> > 
> > https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html
> > 
> > Instead of only accepting comment lines that start with # for serial
> > lines, also accept dnl.
> > ...
> > -my $serial_line_rx = '^#\s*serial\s+(\S*)';
> > +my $serial_line_rx = '^(?:#|dnl)\s*serial\s+(\S*)';
> > 
> > While there's no technical problem with the patch, I'm not sure
> > supporting dnl is desirable. It seems better for the serial line to
> > always end up in whatever file is generated, for the sake of debugging
> > and documentation, instead of being eliminated at m4-time. If there was
> > a specific case where it was better to eliminate it, please describe ...
> 
> This shouldn't make any difference.  In all "normal" uses of aclocal
> everything in these files is going to be diverted to KILL anyway so
> neither form should result in any output text going into configure.
> 
> And with respect to how aclocal imports macro files into a project
> (either as separate files w/ --install, or directly into aclocal.m4),
> it just copies files verbatim so it doesn't matter what syntax is used.
> 
> But by the same token there would seem to be no technical reason to
> prefer dnl over #...

only angle of concern i can think of is that people are using dnl in their code
without realizing it's basically silently ignored.  if we don't want to support
dnl, we should prob be chatty about it at some log level.
-mike


signature.asc
Description: PGP signature

bug#33779: Color-coded output from autoconf/automake (was Re: bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES)

[Mike Frysinger]

On 24 Jan 2023 07:06, Bert Wesarg via Bug reports for Automake wrote:
> On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg  wrote:
> > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake 
> > wrote:
> > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger  wrote:
> > > No, I don't have one. It just crossed my eyes while working on more
> > > silent rules in Automake. I made Ben recently aware of these changes,
> > > which are availalbe here:
> > >
> > > https://github.com/bertwesarg/automake/commits/more-and-colorful-silence
> > >
> > > and also Autoconf is now more colorful:
> > >
> > > https://github.com/bertwesarg/autoconf/commits/color
> >
> > Both of those URLs are 404 for me.
> 
> Its now public.

feel free to send commits to automake-patc...@gnu.org via `git am` for review.
although if you haven't signed FSF copyright papers, we'll want that first.
-mike


signature.asc
Description: PGP signature

[bug#59990] [PATCH] tests: depcomp: ensure make_ok() fails when run_make fails

[Mike Frysinger]

thanks, lgtm, merged
-mike

[bug#60829] [PATCH] m4: use AS_IF to avoid ! portability issues

[Mike Frysinger]

Since the ! builtin has portability issues (as documented in the Autoconf
manual), switch to AS_IF which takes care of these issues for us.

* m4/sanity.m4: Switch `if` to AS_IF.
---
 m4/sanity.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/m4/sanity.m4 b/m4/sanity.m4
index db9a1f5639f1..c24648045e2f 100644
--- a/m4/sanity.m4
+++ b/m4/sanity.m4
@@ -110,10 +110,10 @@ fi
 # If we didn't sleep, we still need to ensure time stamps of config.status and
 # generated files are strictly newer.
 am_sleep_pid=
-if ! test -e conftest.file || grep 'slept: no' conftest.file >/dev/null 2>&1; 
then
+AS_IF([test -e conftest.file || grep 'slept: no' conftest.file >/dev/null 
2>&1],, [dnl
   ( sleep $am_cv_filesystem_timestamp_resolution ) &
   am_sleep_pid=$!
-fi
+])
 AC_CONFIG_COMMANDS_PRE(
   [AC_MSG_CHECKING([that generated files are newer than configure])
if test -n "$am_sleep_pid"; then
-- 
2.39.0

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

[Mike Frysinger]

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

thanks, i'll integrate that idea.  i'm by no means a perl programmer.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 14 Jan 2023 21:43, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > --- a/t/aclocal-no-force.sh
> > +++ b/t/aclocal-no-force.sh
> > @@ -19,6 +19,18 @@
> >  
> >  . test-init.sh
> >  
> > +# Automake relies on high resolution timestamps in perl.  If support isn't
> > +# available (see lib/Automake/FileUtils.pm), then fallback to coarse 
> > sleeps.
> > +# The creative quoting is to avoid spuriously triggering a failure in
> > +# the maintainer checks.
> > +case ${sleep_delay} in
> > +0*)
> > +  if ! $PERL -e 'use Time::HiRes' 2>/dev/null; then
> > +sleep='sleep ''2'
> > +  fi
> > +  ;;
> > +esac
> > +
> 
> I seem to remember being told that "if !" is non-portable.  Is there 
> some other mechanism that ensures this is always run with Bash or might 
> "if $PERL ... ; then :; else" be a better option for that line?

you're right:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Limitations-of-Builtins.html

i'll note that Automake tests have been using `if ! ...` since 1.12 (2012),
and no one seems to have complained.  further, the shell we're using here is
the one autoconf and/or we detected, so it should avoid older broken ones.
i'm inclined to not bend over backwards for this.

> Also, you could write that Perl command as "$PERL -MTime::HiRes -e 1 
> 2>/dev/null" and avoid needing any quotes there, although I suspect this 
> is simply a matter of style and the comment refers to the quotes when 
> setting $sleep.

yes, the quoting comment is referring to the sleep statement.  i can clarify
in the comment by referring to "sleep".

> You could also exploit that || short-circuits in the shell and replace 
> the "if" block with " $PERL ... || sleep='sleep ''2' ".  This allows you 
> to directly execute a command on a false result and (I think) it is 
> portable, too.  (I half-expect someone to correct me on that along the 
> lines of "the shell on Obscurix has a bug where || implicitly uses a 
> subshell".)

personally i find (ab)use of `||` and `&&` tends to lead to unmaintainable code.
i.e. it tends to produce write-once-read-never code akin to most perl.  so if
the construct has been in use already and isn't causing issues, i'd use it.
-mike


signature.asc
Description: PGP signature

[bug#60776] [PATCH] distdir/emacs: avoid `test -d` with MKDIR_P

[Mike Frysinger]

On 14 Jan 2023 17:05, Karl Berry wrote:
> most of the code directly preceding & following this line use @.
> i.e. the vast majority of the current distdir logic.
> 
> Yeah.
> 
> If you feel like changing those @'s to AM_v_at while we're here, sounds
> good to me ... -k

i'd like to give it a bit more thought as to what the output should look
like in general in a non-verbose build, so i'll do it in a follow up
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

Rather than assume such coarse delays, re-use existing logic for
probing the current filesystem resolution.  This speeds up the
testsuite significantly.  On my system, it speeds -j1 up quite a
lot -- by ~30%.  While I didn't gather many samples to produce a
statistically significant distribution, my runs seem to be fairly
consistent with the values below with deviations of <1 minute.

$ time make -j1
BeforeAfter
real  33m17.182s  real  23m33.557s
user  12m12.145s  user  12m12.763s
sys   1m52.308s   sys   1m52.853s

$ time make -j32
BeforeAfter
real  1m35.874s   real  1m4.908s
user  14m24.664s  user  15m58.663s
sys   2m9.297ssys   2m27.393s

* configure.ac: Set test delays to am_cv_filesystem_timestamp_resolution.
* t/aclocal-no-force.sh: Use slower sleep if subsecond APIs are missing.
* t/ax/test-defs.in: Split sleep settings into separate variables.
---
 configure.ac  | 10 +-
 t/aclocal-no-force.sh | 12 
 t/ax/test-defs.in |  5 ++---
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index dcf2d95566a0..d3a67d5ffec9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -172,15 +172,7 @@ result=no
 test "x$am_cv_prog_ln" = xln && result=yes
 AC_MSG_RESULT([$result])
 
-# The amount we should wait after modifying files depends on the platform.
-# On Windows '95, '98 and ME, files modifications have 2-seconds
-# granularity and can be up to 3 seconds in the future w.r.t. the
-# system clock.  When it is important to ensure one file is older
-# than another we wait at least 5 seconds between creations.
-case $build in
-  *-pc-msdosdjgpp) MODIFICATION_DELAY=5;;
-  *)   MODIFICATION_DELAY=2;;
-esac
+MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution
 AC_SUBST([MODIFICATION_DELAY])
 
 ## --- ##
diff --git a/t/aclocal-no-force.sh b/t/aclocal-no-force.sh
index 3e0c04d12f18..2e139d75cf74 100644
--- a/t/aclocal-no-force.sh
+++ b/t/aclocal-no-force.sh
@@ -19,6 +19,18 @@
 
 . test-init.sh
 
+# Automake relies on high resolution timestamps in perl.  If support isn't
+# available (see lib/Automake/FileUtils.pm), then fallback to coarse sleeps.
+# The creative quoting is to avoid spuriously triggering a failure in
+# the maintainer checks.
+case ${sleep_delay} in
+0*)
+  if ! $PERL -e 'use Time::HiRes' 2>/dev/null; then
+sleep='sleep ''2'
+  fi
+  ;;
+esac
+
 cat >> configure.ac << 'END'
 SOME_DEFS
 AC_CONFIG_FILES([sub/Makefile])
diff --git a/t/ax/test-defs.in b/t/ax/test-defs.in
index e09a387cd0a6..321602cfdd0b 100644
--- a/t/ax/test-defs.in
+++ b/t/ax/test-defs.in
@@ -180,9 +180,8 @@ TEX=${AM_TESTSUITE_TEX-'@TEX@'}
 # The amount we should wait after modifying files depends on the platform.
 # For instance, Windows '95, '98 and ME have 2-second granularity
 # and can be up to 3 seconds in the future w.r.t. the system clock.
-# The creative quoting is to avoid spuriously triggering a failure in
-# the maintainer checks,
-sleep='sleep ''@MODIFICATION_DELAY@'
+sleep_delay=@MODIFICATION_DELAY@
+sleep="sleep ${sleep_delay}"
 
 # An old timestamp that can be given to a file, in "touch -t" format.
 # The time stamp should be portable to all file systems of interest.
-- 
2.39.0

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

[Mike Frysinger]

On 14 Jan 2023 14:52, Karl Berry wrote:
> +my $have_time_hires = eval { require Time::HiRes; };
> 
> I don't object. Although if there's no speed up in practice, I wonder if
> it's worth the extra code (simple-enough though it is). -k

there's no speed up in the execution of a single process, but there is a
speedup for users when using these tools back-to-back as they don't have
to regen as often.  this fix is necessary for the next patch to speed up
the testsuite by using a smaller delay.

although that makes me realize i need to make the next patch work when
the system doesn't have Time::HiRes so users don't hit test failures.
there was only one test that checks current behavior, so shouldn't be
too bad.
-mike


signature.asc
Description: PGP signature

[bug#60776] [PATCH] distdir/emacs: avoid `test -d` with MKDIR_P

[Mike Frysinger]

On 14 Jan 2023 15:17, Karl Berry wrote:
> imo we overly rely on explicit @ in many places which can make debugging
> failures painful.
> 
> FWIW, I agree. Although I see no @ here.

most of the code directly preceding & following this line use @.
i.e. the vast majority of the current distdir logic.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

Perl's builtin stat function returns timestamps that have 1 second
resolution.  This can lead automake needlessly regenerating files
because it compares timestamps as "older than or equal to" rather
than only "older than".  This is perfectly reasonable as we have
no way of knowing what file is older if they have the same value
which means we must be pessimistic & assume an upate is required.

However, given modern systems that are quite fast and can easily
generate many files in less than an second, we end up doing a lot
of extra work.

Until Perl gets around to figuring out how to support subsecond
timestamp resolution, optionally import the Time::HiRes module and
use its stat function instead.  If it's available, great, if not,
then we're no worse off than we are today.

Performance-wise, at least by using the testsuite, there doesn't
seem to be any measurable difference.

* lib/Automake/FileUtils.pm: Use Time::HiRes to lookup mtimes on
files if available.
---
 lib/Automake/FileUtils.pm | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lib/Automake/FileUtils.pm b/lib/Automake/FileUtils.pm
index 848ff22d1761..78e0942e9f53 100644
--- a/lib/Automake/FileUtils.pm
+++ b/lib/Automake/FileUtils.pm
@@ -42,6 +42,11 @@ use Exporter;
 use File::stat;
 use IO::File;
 
+# Perl's builtin stat does not provide sub-second resolution.  Use Time::HiRes
+# if it's available instead.  Hopefully one day perl will update.
+# https://github.com/Perl/perl5/issues/17900
+my $have_time_hires = eval { require Time::HiRes; };
+
 use Automake::Channels;
 use Automake::ChannelDefs;
 
@@ -115,10 +120,18 @@ sub mtime ($)
   return 0
 if $file eq '-' || ! -f $file;
 
-  my $stat = stat ($file)
-or fatal "cannot stat $file: $!";
-
-  return $stat->mtime;
+  if ($have_time_hires)
+{
+  my @stat = Time::HiRes::stat ($file)
+   or fatal "cannot stat $file: $!";
+  return $stat[9];
+}
+  else
+{
+  my $stat = stat ($file)
+   or fatal "cannot stat $file: $!";
+  return $stat->mtime;
+}
 }
 
 
-- 
2.39.0

[bug#60808] [PATCH 2/2] tests: reuse am_cv_filesystem_timestamp_resolution

[Mike Frysinger]

Rather than assume such coarse delays, re-use existing logic for
probing the current filesystem resolution.  This speeds up the
testsuite significantly.  On my system, it speeds -j1 up quite a
lot -- by ~30%.  While I didn't gather many samples to produce a
statistically significant distribution, my runs seem to be fairly
consistent with the values below with deviations of <1 minute.

$ time make -j1
BeforeAfter
real  33m17.182s  real  23m33.557s
user  12m12.145s  user  12m12.763s
sys   1m52.308s   sys   1m52.853s

$ time make -j32
BeforeAfter
real  1m35.874s   real  1m4.908s
user  14m24.664s  user  15m58.663s
sys   2m9.297ssys   2m27.393s

* configure.ac: Set test delays to am_cv_filesystem_timestamp_resolution.
---
 configure.ac | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index dcf2d95566a0..d3a67d5ffec9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -172,15 +172,7 @@ result=no
 test "x$am_cv_prog_ln" = xln && result=yes
 AC_MSG_RESULT([$result])
 
-# The amount we should wait after modifying files depends on the platform.
-# On Windows '95, '98 and ME, files modifications have 2-seconds
-# granularity and can be up to 3 seconds in the future w.r.t. the
-# system clock.  When it is important to ensure one file is older
-# than another we wait at least 5 seconds between creations.
-case $build in
-  *-pc-msdosdjgpp) MODIFICATION_DELAY=5;;
-  *)   MODIFICATION_DELAY=2;;
-esac
+MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution
 AC_SUBST([MODIFICATION_DELAY])
 
 ## --- ##
-- 
2.39.0

bug#55025: Automake should allow one to enable POSIX make behavior

[Mike Frysinger]

On 14 Jan 2023 01:30, Nick Bowler wrote:
> On 2023-01-13, Mike Frysinger  wrote:
> > On 13 Jan 2023 16:01, Karl Berry wrote:
> >> I am doubtful about blithely defining .POSIX unconditionally. I feel
> >> sure that will break existing Makefiles. I don't think we should do that.
> >>
> >> Detecting .POSIX in an existing Makefile.am and moving it to the front
> >> sounds desirable, since that is clearly what the developer intended.
> >>
> >> Another (not mutually exclusive) possibility is to add an Automake
> >> option (say, "make-posix") that outputs the .POSIX line. --thanks, karl.
> >
> > i'd be amenable to a `no-make-posix` option, but imo forcing people to
> > opt-in to the right behavior is the wrong mental model.
> 
> Does adding .POSIX: to a Makefile actually solve any real-world
> portability problem with Automake generated makefiles, or is all of
> this just hypothetical?
> 
> Because we shouldn't go changing default behaviour to solve imaginary
> problems ...
> 
> > i'm also a bit skeptical of the idea that we're breaking makefiles.
> 
> ... and adding this to a Makefile really does change the behaviour
> significantly on at least one popular make implementation (GNU make).
> 
> I imagine a lot of people who are unfamiliar with traditional UNIX
> implementations would be very surprised to see gmake suddenly start
> running their rules using /bin/sh -e, which is probably the most
> obvious effect that the .POSIX special target has on this particular
> implementation.
> 
> And it doesn't even seem to work to get GNU make to follow the POSIX
> behaviour, as POSIX says -e is NOT used whenever errors are being
> suppressed (that is, when running commands that start with a -, or
> if the .IGNORE: special target is present in the makefile, or if
> make is run with the -i option).  GNU make appears to just always
> run the shell with -e if you include the .POSIX special target.

if this is the case, then it sounds like a bug.  at a glance, i don't see a
report in the upstream tracker, so can you throw one up there if you have a
test case that shows the problem ?

> Even then, portable makefiles can't rely on the shell being run
> with -e even normally, as NetBSD make does not do this.
> 
> I tried several other implementations and they follow the POSIX
> behaviour by default, adding -e only when errors are not suppressed.

this is exactly my point.  if i'm developing a project with automake and i'm
using gnu make, i can easily produce bad code that is not portable.  but the
insidious part is that it doesn't fail for me, it fails for my users who are
not using gnu make, but using a POSIX-compliant implementation that respects
the `set -e` behavior.

the reason i use automake in my projects in the first place is to produce a
build env that is reasonably portable, and if i have to write custom hooks,
to help steer me away from non-POSIX (i.e. things likely to not be portable)
constructs.
-mike


signature.asc
Description: PGP signature

[bug#60772] [PATCH] tests: rework gettext to only check 'external' behavior

[Mike Frysinger]

On 13 Jan 2023 16:52, Karl Berry wrote:
> Subject: [bug#60772] [PATCH] tests: rework gettext to only check 
> 'external'
>  behavior
> 
> Good catch, thanks. Please commit.
> 
> +# po/ is required.  intl/ should not be used.
> 
> Perhaps add the bit of information from your mail to help future
> sleuths:
> 
> "... not be used, since non-external use of gettext was deprecated in
> 2010 (gettext 0.18) and made fatal in 0.20 (2019)."

will do, and have done
-mike


signature.asc
Description: PGP signature

bug#54421: AM_PROG_AR and LT_INIT don't work together when using lib.exe

[Mike Frysinger]

On 13 Jan 2023 13:52, Tim Ruffing wrote:
> On Fri, 2023-01-13 at 05:52 +0000, Mike Frysinger wrote:
> > i think the expectation is that, if you're using libtool, then you
> > use libtool.  
> 
> Well, I *use* libtool. libtool needs some AR. I choose to use
> libtool.exe with the ar-lib wrapper. 

you wondered why no one has reported/noticed hits before.  i gave you
an explanation.  what you're doing is unusual, and so far, i haven't
seen an explanation as to why you're doing something unusual.  so the
(implicit) question still stands: why are you using Automake's archive
(ar-lib) logic when libtool already provides support for doing the same
thing -- creating static archives.

should we fix it ?  probably.  is it worth the effort ?  maybe not.
would we accept patches from someone who wants to spend the time ?
depends on the patch.
-mike


signature.asc
Description: PGP signature

bug#55025: Automake should allow one to enable POSIX make behavior

[Mike Frysinger]

On 13 Jan 2023 16:01, Karl Berry wrote:
> I am doubtful about blithely defining .POSIX unconditionally. I feel
> sure that will break existing Makefiles. I don't think we should do that.
> 
> Detecting .POSIX in an existing Makefile.am and moving it to the front
> sounds desirable, since that is clearly what the developer intended.
> 
> Another (not mutually exclusive) possibility is to add an Automake
> option (say, "make-posix") that outputs the .POSIX line. --thanks, karl.

i'd be amenable to a `no-make-posix` option, but imo forcing people to
opt-in to the right behavior is the wrong mental model.

i'm also a bit skeptical of the idea that we're breaking makefiles.  if
an implementation is POSIX compliant, then it already behaves as POSIX
defines make.  as it stands now, we, and our users, are generating files
that target an undefined standard that no one agrees on, cannot be tested
or asserted, and maybe they happen to work on the developer's desktop, but
not on random users of their own.  by defining .POSIX, we turn the state
from "usually works, but sometimes fails" to "either works or fails, but
it's the same everywhere".

i grok that not everyone is POSIX-compliant, and we sometimes try to add
support for such systems where reasonable, but that's a case-by-case, and
we can't keep bending over backwards to support decades old dead software
that no one uses.
-mike


signature.asc
Description: PGP signature

[bug#60776] [PATCH] distdir/emacs: avoid `test -d` with MKDIR_P

[Mike Frysinger]

On 13 Jan 2023 15:36, Karl Berry wrote:
> - test -d "$(distdir)" || mkdir "$(distdir)"
> + $(AM_V_at)$(MKDIR_P) "$(distdir)"
> 
> Ok by me, but why the AM_V_at for this particular command?
> I don't see it used anywhere else in distdir.am.

this is certainly true, and it's something i want to fix ... at some point.
imo we overly rely on explicit @ in many places which can make debugging
failures painful.  i imagine the current state is due to the silent-rules
work focusing on the most common paths (compile/rebuilds) and leaving the
rest to "one day".  so if we ever get to that day, we'd use $(AM_V_at) in
this location.  i figured making the change while i was here means we have
a slightly higher chance of this code eventually being silent-rules compat
vs finding the time to convert it all at once.
-mike


signature.asc
Description: PGP signature

[bug#59994] [PATCH] tests: Don't try to prevent flex to include unistd.h

[Mike Frysinger]

On 13 Jan 2023 13:49, Frederic Berat wrote:
> I probably won't be able to do so before next week at least.
> If you happen to have time (and be willing) to do it earlier, don't
> hesitate ;)

that timeframe is fine.  as you can see, we take a long view in Automake.
-mike


signature.asc
Description: PGP signature

[bug#60776] [PATCH] distdir/emacs: avoid `test -d` with MKDIR_P

[Mike Frysinger]

We don't need to do the `test -d ... || mkdir ...` dance when we
have the MKDIR_P helper, so simplify this code a bit.

* lib/am/distdir.am: Use $(MKDIR_P).
* lib/am/lisp.am: Drop redundant `test -d`.
---
 lib/am/distdir.am | 2 +-
 lib/am/lisp.am| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 4cfc742ce23d..264713c332e6 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -103,7 +103,7 @@ endif %?TOPDIR_P%
 ##
 if %?TOPDIR_P%
$(am__remove_distdir)
-   test -d "$(distdir)" || mkdir "$(distdir)"
+   $(AM_V_at)$(MKDIR_P) "$(distdir)"
 endif %?TOPDIR_P%
 ##
 ##
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index d5858f8661af..c96be2121656 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -37,7 +37,7 @@ endif %?INSTALL%
am__subdir_includes="-L $$am__dir -L $(srcdir)/$$am__dir"; \
  esac; \
 ## Emacs byte-compilation won't create this automatically, sadly.
- test -d "$$am__dir" || $(MKDIR_P) "$$am__dir" || exit 1; \
+ $(MKDIR_P) "$$am__dir" || exit 1; \
  $(EMACS) --batch --no-site-file \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-- 
2.39.0

[bug#59993] [PATCH v2 3/3] tests: Fix implicit function declaration in ax/depcomp.sh

[Mike Frysinger]

On 13 Jan 2023 09:14, Frederic Berat wrote:
> I made one more build with a different patchset list, could it be that the
> failure you encounter is with "t/subobj.sh" ?

to be clear, i applied this patch only to current git master.  i didn't try
including anything else.  with that in mind, the failure is not in that, but
in t/depcomp-auto.tap.
FAIL: t/depcomp-auto
FAIL: t/depcomp-auto.tap 14 - [simple VPATH] make distclean
FAIL: t/depcomp-auto.tap 21 - [long VPATH] make distclean
FAIL: t/depcomp-auto.tap 28 - [absolute VPATH] make distclean

ERROR: files left in build directory after distclean:
./.deps/foo.Tpo
make: *** [Makefile:750: distcleancheck] Error 1
-mike


signature.asc
Description: PGP signature

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

[Mike Frysinger]

On 13 Jan 2023 07:07, Sam James wrote:
> $ /tmp/libaacs/configure YACC=bison LEX=flex

the problem is you're forcing `YACC=bison`.  Automake defaults to `bison -y`
which tells bison to operate in POSIX-yacc-compatible mode because Automake's
rules target POSIX.  the end result is that you've forced a non-POSIX mode,
and bison is writing files to the cwd which is not what Automake expects.
it isn't that the src/file/ directory doesn't exist -- you can see from your
log that files have been generated in src/file/ before the failure.
-mike


signature.asc
Description: PGP signature

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

[Mike Frysinger]

On 13 Jan 2023 06:29, Sam James wrote:
> > On 13 Jan 2023, at 06:13, Mike Frysinger  wrote:
> > On 14 Mar 2022 17:21, Sam James wrote:
> >> It appears that YACC rules don't check for whether the destination 
> >> directory exists before executing ylwrap.
> >> 
> >> When trying to package libaacs 
> >> (https://code.videolan.org/videolan/libaacs) with an out-of-source build, 
> >> I hit an unexpected build failure:
> >> ```
> >> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
> >>  warning: fix-its can be applied.  Rerun with option '--update'. [-Wother]
> >> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
> >>  206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
> >> updating src/file/keydbcfg-parser.h
> >> mv: cannot move 'tmp-keydbcfg-parser.h' to 
> >> '../src/file/keydbcfg-parser.h': No such file or directory
> >> make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
> >> ```
> >> 
> >> I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to 
> >> ensure that the necessary directory exists within the build directory 
> >> beforehand, but
> >> it feels like I shouldn't have to.
> >> 
> >> Their Makefile.am can be found here: 
> >> https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am. 
> >> Snippet:
> >> ```
> >> libaacs_la_SOURCES=\
> >> src/libaacs/aacs.h \
> >> [...]
> >> src/file/dirs.h \
> >> src/file/file.h \
> >> src/file/file.c \
> >> src/file/filesystem.h \
> >> src/file/filesystem.c \
> >> src/file/keydbcfg.c \
> >> src/file/keydbcfg.h \
> >> src/file/keydb.h \
> >> src/file/keydbcfg-parser.y \
> >> src/file/keydbcfg-lexer.l \
> >> src/file/mmc_device.h \
> >> [...]
> >> ```
> >> 
> >> While src/libaacs exists within the build dir, src/file/ doesn't exist at 
> >> all, hence the failure.
> >> 
> >> automake yacc rules should mkdir -p the needed directories within the 
> >> build dir for VPATH builds before running ylwrap/yacc.
> > 
> > i think there's more to it.  if you're using a release tarball for this 
> > project
> > created by `make dist`, then you shouldn't be running yacc in the first 
> > place.
> > 
> > https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
> 
> Curiosity got the better of me (see previous reply) so:
> ```
> $ cd /tmp
> $ git clone https://code.videolan.org/videolan/libaacs/
> $(cd libaacs && ./bootstrap.sh)
> $mkdir libaacs-oos && cd libaacs

guessing you meant `cd libaacs-oos`

> $ /tmp/libaacs/configure YACC=bison LEX=flex
> $ make
> $ make
>   YACC src/file/keydbcfg-parser.c
> keydbcfg-parser.tab.c is unchanged
> keydbcfg-parser.tab.h is unchanged
> make[1]: Entering directory '/tmp/libaacs-oos'
>   YACC src/file/keydbcfg-parser.c
> keydbcfg-parser.tab.c is unchanged
> keydbcfg-parser.tab.h is unchanged
> make[1]: Leaving directory '/tmp/libaacs-oos'
> make  all-am
> make[1]: Entering directory '/tmp/libaacs-oos'
>   YACC src/file/keydbcfg-parser.c
> keydbcfg-parser.tab.c is unchanged
> keydbcfg-parser.tab.h is unchanged
>   CC   src/file/keydbcfg-parser.lo
> cc1: fatal error: src/file/keydbcfg-parser.c: No such file or directory
> compilation terminated.
> make[1]: *** [Makefile:1009: src/file/keydbcfg-parser.lo] Error 1
> make[1]: Leaving directory '/tmp/libaacs-oos'
> make: *** [Makefile:638: all] Error 2
> ```
> 
> so it's still looking in the source rather than the build directory for the 
> generated file?

i'm not sure what you're trying to show here.  that running make twice in a
row produces weird/inconsistent results ?  if that's the case, that's not
the behavior i'm seeing over here.

i'll note that the default configure+make works because dependency tracking
is enabled which prepopulates the directory tree.  it's failing for you in
Gentoo because econf automatically adds --disable-dependency-tracking which
turns all that logic off, and the directory tree doesn't exist.

Automake is VPATH-ing the source file.  we prob should change that to use an
explicit $(srcdir) prefix when nodist is not utilized.  then it would always
write the generated .c/.h to the source tree.
-mike


signature.asc
Description: PGP signature

[bug#59993] [PATCH v2 3/3] tests: Fix implicit function declaration in ax/depcomp.sh

[Mike Frysinger]

this breaks `make check`, so i can't merge it
-mike

[bug#59992] [PATCH 1/2] tests: Fix 'type defaults' error in link_cond due to main not being properly declared

[Mike Frysinger]

thanks, merged now
-mike

[bug#59992] [PATCH 1/2] tests: Fix 'type defaults' error in link_cond due to main not being properly declared

[Mike Frysinger]

severity 59992 wishlist
close 59992
thankyou

[bug#59994] [PATCH] tests: Don't try to prevent flex to include unistd.h

[Mike Frysinger]

On Mon, 12 Dec 2022 15:20:46 -0500, Zack Weinberg wrote:
> On 2022-12-12 2:07 AM, Frederic Berat wrote:
> > 
> > This patch is mainly a proposal. While the macro can simply be removed
> > as explained below, another possibility it to add a flex option
> > "--never-interactive" to prevent flex to make use of "isatty".
> >
> > This is related to an effort to prepare Automake for future GCC/Clang
> > versions which set c99 as default standard to be used.
> > 
> > Future version of flex make the "NO_UNISTD" flag a no-op, and include
> > unistd.h by default.
> > 
> > In current version of flex, not having this header leads to implicit
> > function declarations that are not compatible with c99 standard.
> > 
> > On top of that, while flex dedicated test were having this macro set,
> > the yacc ones didn't have it despise their use of Flex. Thus, if this
> > macro was ever useful, it looks like nobody actually cared.
>
> I'm guessing that the idea here was to avoid using unistd.h on platforms 
> that don't supply that header at all.  I suggest that we should apply 
> your patch *and* consistently test flex with "--never-interactive".

sounds fine.  want to update your patch Frederic ?
-mike

bug#55025: Automake should allow one to enable POSIX make behavior

[Mike Frysinger]

On 19 Apr 2022 17:33, Vincent Lefevre wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
> says about the target rules:
> 
>   .POSIX
> The application shall ensure that this special target is specified
> without prerequisites or commands. If it appears as the first
> non-comment line in the makefile, /make/ shall process the makefile
> as specified by this section; otherwise, the behavior of /make/ is
> unspecified.
> 
> But even though one may add a .POSIX target as the first non-comment
> line in one's Makefile.am file, Automake will add various non-comment
> lines before this target in the generated Makefile. I received a
> remark about that for GNU MPFR. Though GNU make does not require
> this target to be the first non-comment line, this may matter with
> other make implementations.
> 
> This could be done either by detecting a .POSIX target in Makefile.am
> or with some AM_* macro in the configure.ac file.

any reason we don't just define it ourselves unconditionally ?  seems
like the whole point of Automake is for devs to not worry about these
kind of nitty details.
-mike

--- a/lib/am/header-vars.am
+++ b/lib/am/header-vars.am
@@ -14,6 +14,8 @@
 ## You should have received a copy of the GNU General Public License
 ## along with this program.  If not, see .
 
+.POSIX:
+
 VPATH = @srcdir@
 
 @SET_MAKE@


signature.asc
Description: PGP signature

bug#54390: YACC rules don't check DESTDIR existence for VPATH builds

[Mike Frysinger]

On 14 Mar 2022 17:21, Sam James wrote:
> It appears that YACC rules don't check for whether the destination directory 
> exists before executing ylwrap.
> 
> When trying to package libaacs (https://code.videolan.org/videolan/libaacs) 
> with an out-of-source build, I hit an unexpected build failure:
> ```
> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
>  warning: fix-its can be applied.  Rerun with option '--update'. [-Wother]
> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
>  206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
> updating src/file/keydbcfg-parser.h
> mv: cannot move 'tmp-keydbcfg-parser.h' to '../src/file/keydbcfg-parser.h': 
> No such file or directory
> make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
> ```
> 
> I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to ensure 
> that the necessary directory exists within the build directory beforehand, but
> it feels like I shouldn't have to.
> 
> Their Makefile.am can be found here: 
> https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am. Snippet:
> ```
> libaacs_la_SOURCES=\
>   src/libaacs/aacs.h \
> [...]
>   src/file/dirs.h \
>   src/file/file.h \
>   src/file/file.c \
>   src/file/filesystem.h \
>   src/file/filesystem.c \
>   src/file/keydbcfg.c \
>   src/file/keydbcfg.h \
>   src/file/keydb.h \
>   src/file/keydbcfg-parser.y \
>   src/file/keydbcfg-lexer.l \
>   src/file/mmc_device.h \
> [...]
> ```
> 
> While src/libaacs exists within the build dir, src/file/ doesn't exist at 
> all, hence the failure.
> 
> automake yacc rules should mkdir -p the needed directories within the build 
> dir for VPATH builds before running ylwrap/yacc.

i think there's more to it.  if you're using a release tarball for this project
created by `make dist`, then you shouldn't be running yacc in the first place.

https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
> The intermediate files generated by yacc (or lex) will be included in any
> distribution that is made. That way the user doesn’t need to have yacc or lex.

cloning that repo and running `make dist` shows the file is generated, and it's
listed in am__DIST_COMMON, but it still doesn't make it into the tarball.  oh,
it looks like this is self-inflicted:
https://code.videolan.org/videolan/libaacs/-/blob/0.11.1/Makefile.am#L88
https://code.videolan.org/videolan/libaacs/-/commit/f60f46da1dc5e87f70b6edc965a8909d3f21c247

that makes no sense.  file a bug with them.
-mike


signature.asc
Description: PGP signature

bug#33779: Wrong lib-list in install-%DIR%LTLIBRARIES

[Mike Frysinger]

On Mon, 17 Dec 2018 20:11:48 +0100, Bert Wesarg wrote:
> looking at lib/am/ltlib.am, the rule for installing libraries looks
> weird for the !LIBTOOL case. Though I have the impression that this
> file should not be used at all, if libtool is not used. Nevertheless,
> the install command in this cases uses the $list variable, not the
> sanitized $list2 variable. A simple patch looks like:

i agree it looks funky.  do you have an example of where this fails ?
how did you discover the bug ?  we'd want to write a test for it so we
can be sure it doesn't fail again.
-mike

bug#60773: AM_PROG_AR and LT_INIT don't work together when using lib.exe

[Mike Frysinger]

On Wed, 16 Mar 2022 15:24:37 +0100, Tim Ruffing wrote:
> Assume environment variable AR="lib.exe" and configure.ac has
>
> ```
> AM_PROG_AR
> LT_INIT
> ```

i think the expectation is that, if you're using libtool, then you
use libtool.  it can create static convenience libraries too:
https://www.gnu.org/software/libtool/manual/html_node/Static-libraries.html
-mike

[bug#60772] [PATCH] tests: rework gettext to only check 'external' behavior

[Mike Frysinger]

The gettext project deprecated non-external use back in 2010 with the
0.18 release, and made it fatal with the 0.20 release in 2019.  With
that version, calling AM_GNU_GETTEXT() fails, which means all Automake
tests are now skipped.  The t/gettext-macros.sh helper probes gettext
as such:

>+ autopoint --force
>  autopoint: *** AM_GNU_GETTEXT without 'external' argument is no longer 
> supported in version 0.21.1
>  autopoint: *** Stop.
> ...
>+ aclocal-1.16 -Werror -Wno-syntax -I m4 --install
>  aclocal-1.16: warnings are treated as errors
>  configure.ac:4: warning: macro 'AM_GNU_GETTEXT' not found in library
>  configure.ac:5: warning: macro 'AM_GNU_GETTEXT_VERSION' not found in library
>+ echo skip_all_ "couldn't find or get gettext macros"

Since t/gettext-macros.sh generates a helper that all other gettext
tests use to see if gettext is available, all they get skipped.

Rework our existing tests to only check the 'external' gettext mode.
This should work with older versions, and we don't really need to
keep track of old non-external mode since it's been deprecated for
so long.

* t/gettext-basics.sh: Use external gettext mode, and adjust tests.
* t/gettext-config-rpath.sh: Likewise.
* t/gettext-macros.sh: Likewise.
* t/gettext-pr381.sh: Likewise.
* t/subdir-cond-gettext.sh: Likewise.
---
 t/gettext-basics.sh   | 19 ++-
 t/gettext-config-rpath.sh |  6 +++---
 t/gettext-macros.sh   |  2 +-
 t/gettext-pr381.sh|  2 +-
 t/subdir-cond-gettext.sh  |  6 +++---
 5 files changed, 14 insertions(+), 21 deletions(-)

diff --git a/t/gettext-basics.sh b/t/gettext-basics.sh
index 93fe782f4027..6d733928c68f 100644
--- a/t/gettext-basics.sh
+++ b/t/gettext-basics.sh
@@ -20,7 +20,7 @@ required='gettext'
 . test-init.sh
 
 cat >> configure.ac << 'END'
-AM_GNU_GETTEXT
+AM_GNU_GETTEXT([external])
 AC_OUTPUT
 END
 
@@ -31,28 +31,21 @@ mkdir po intl
 $ACLOCAL
 $AUTOCONF
 
-# po/ and intl/ are required.
+# po/ is required.  intl/ should not be used.
 
 AUTOMAKE_fails --add-missing
 grep 'AM_GNU_GETTEXT.*SUBDIRS' stderr
 
 echo 'SUBDIRS = po' >Makefile.am
-AUTOMAKE_fails --add-missing
-grep 'AM_GNU_GETTEXT.*intl' stderr
+# Should not fail.
+$AUTOMAKE --add-missing
 
 echo 'SUBDIRS = intl' >Makefile.am
 AUTOMAKE_fails --add-missing
 grep 'AM_GNU_GETTEXT.*po' stderr
 
-# Ok.
-
 echo 'SUBDIRS = po intl' >Makefile.am
-$AUTOMAKE --add-missing
-
-# Make sure distcheck runs './configure --with-included-gettext'.
-./configure
-echo distdir: > po/Makefile
-echo distdir: > intl/Makefile
-$MAKE -n distcheck | grep '.*--with-included-gettext'
+AUTOMAKE_fails --add-missing
+grep 'intl.*SUBDIRS.*AM_GNU_GETTEXT' stderr
 
 :
diff --git a/t/gettext-config-rpath.sh b/t/gettext-config-rpath.sh
index 3953a0c3df83..522b42fce967 100644
--- a/t/gettext-config-rpath.sh
+++ b/t/gettext-config-rpath.sh
@@ -20,14 +20,14 @@ required='gettext'
 . test-init.sh
 
 cat >> configure.ac << 'END'
-AM_GNU_GETTEXT
+AM_GNU_GETTEXT([external])
 # config.rpath is required by versions >= 0.14.3.
 AM_GNU_GETTEXT_VERSION([0.14.3])
 AC_OUTPUT
 END
 
-echo 'SUBDIRS = po intl' >Makefile.am
-mkdir po intl
+echo 'SUBDIRS = po' >Makefile.am
+mkdir po
 
 # If aclocal fails here, it may be that gettext is too old to provide
 # AM_GNU_GETTEXT_VERSION.  Similarly, autopoint will fail if it's
diff --git a/t/gettext-macros.sh b/t/gettext-macros.sh
index e352e679079e..c91f005a1e3b 100644
--- a/t/gettext-macros.sh
+++ b/t/gettext-macros.sh
@@ -48,7 +48,7 @@ cat > configure.ac <> configure.ac << 'END'
-AM_GNU_GETTEXT
+AM_GNU_GETTEXT([external])
 AC_OUTPUT
 END
 
diff --git a/t/subdir-cond-gettext.sh b/t/subdir-cond-gettext.sh
index 023eff134885..a203c025d308 100644
--- a/t/subdir-cond-gettext.sh
+++ b/t/subdir-cond-gettext.sh
@@ -20,18 +20,18 @@ required=gettext
 . test-init.sh
 
 cat >> configure.ac << 'END'
-AM_GNU_GETTEXT
+AM_GNU_GETTEXT([external])
 AM_CONDITIONAL([MAUDE], [true])
 ALL_LINGUAS=
 AC_SUBST([ALL_LINGUAS])
 END
 
-mkdir po intl
+mkdir po
 : >config.rpath
 
 cat > Makefile.am << 'END'
 if MAUDE
-SUBDIRS = po intl
+SUBDIRS = po
 else
 SUBDIRS =
 endif
-- 
2.39.0

[bug#60771] [PATCH] tests: disable git log pager usage

[Mike Frysinger]

When running this code locally, the git log call can trigger a pager
depending on the local settings, which in turn forces the test to be
interactive.  Run git with --no-pager to force disable it.

* t/get-sysconf.sh: Run git with --no-pager.
---
 t/get-sysconf.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/get-sysconf.sh b/t/get-sysconf.sh
index 11aa48bde3a3..016e60491938 100644
--- a/t/get-sysconf.sh
+++ b/t/get-sysconf.sh
@@ -25,7 +25,7 @@
 st=0
 if test -d "$am_top_srcdir"/.git; then
   # We are running from a git checkout.
-  (cd "$am_top_srcdir" && git log -1) || st=1
+  (cd "$am_top_srcdir" && git --no-pager log -1) || st=1
 elif test -f "$am_top_srcdir"/ChangeLog; then
   # We are probably running from a distribution tarball.
   awk '
-- 
2.39.0

[bug#60764] [PATCH] tests: change `sort|uniq` to `sort -u`

[Mike Frysinger]

These are equivalent, but more performant.  We already use `sort -u`
elsewhere in the codebase, so nothing new here really.

* t/add-missing.tap: Change `sort|uniq` to `sort -u`.
* t/CheckListOfTests.am: Likewise.
---
 t/CheckListOfTests.am | 2 +-
 t/add-missing.tap | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/CheckListOfTests.am b/t/CheckListOfTests.am
index e17083a62d47..672af700e88b 100644
--- a/t/CheckListOfTests.am
+++ b/t/CheckListOfTests.am
@@ -49,7 +49,7 @@ maintainer-check-list-of-tests:
   ($(am__cd) $(srcdir) && ls $$dir/*$$ext 2>/dev/null); \
 fi; \
   done; \
-done | sed 's,^\./,,' | sort | uniq >$(am__tfs); \
+done | sed 's,^\./,,' | sort -u >$(am__tfs); \
 ## Compare the two lists, complain if they differ.
 if $$diff $(am__tmk) $(am__tfs) >$(am__tdf); then \
result=0; \
diff --git a/t/add-missing.tap b/t/add-missing.tap
index 010c03ec5864..ea42bc9cda05 100644
--- a/t/add-missing.tap
+++ b/t/add-missing.tap
@@ -196,7 +196,7 @@ check_ ()
 # Only the expected files should be installed.  But automake always
 # require 'missing' and 'install-sh', so account for them.
 all_files="install-sh missing $files"
-for f in $all_files; do echo $f; done | sort | uniq > files.exp
+for f in $all_files; do echo $f; done | sort -u > files.exp
 (cd $build_aux && ls) | sort > files.got
 cat files.exp
 cat files.got
-- 
2.39.0

[bug#60763] [PATCH] tests: change `sort|uniq` to `sort -u`

[Mike Frysinger]

These are equivalent, but more performant.  We already use `sort -u`
elsewhere in the codebase, so nothing new here really.

* t/add-missing.tap: Change `sort|uniq` to `sort -u`.
* t/CheckListOfTests.am: Likewise.
---
 t/CheckListOfTests.am | 2 +-
 t/add-missing.tap | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/CheckListOfTests.am b/t/CheckListOfTests.am
index e17083a62d47..672af700e88b 100644
--- a/t/CheckListOfTests.am
+++ b/t/CheckListOfTests.am
@@ -49,7 +49,7 @@ maintainer-check-list-of-tests:
   ($(am__cd) $(srcdir) && ls $$dir/*$$ext 2>/dev/null); \
 fi; \
   done; \
-done | sed 's,^\./,,' | sort | uniq >$(am__tfs); \
+done | sed 's,^\./,,' | sort -u >$(am__tfs); \
 ## Compare the two lists, complain if they differ.
 if $$diff $(am__tmk) $(am__tfs) >$(am__tdf); then \
result=0; \
diff --git a/t/add-missing.tap b/t/add-missing.tap
index 010c03ec5864..ea42bc9cda05 100644
--- a/t/add-missing.tap
+++ b/t/add-missing.tap
@@ -196,7 +196,7 @@ check_ ()
 # Only the expected files should be installed.  But automake always
 # require 'missing' and 'install-sh', so account for them.
 all_files="install-sh missing $files"
-for f in $all_files; do echo $f; done | sort | uniq > files.exp
+for f in $all_files; do echo $f; done | sort -u > files.exp
 (cd $build_aux && ls) | sort > files.got
 cat files.exp
 cat files.got
-- 
2.39.0

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

[Mike Frysinger]

On 05 Jan 2023 16:47, Karl Berry wrote:
> Please excuse my curmudgeonness, but it's not clear to me that avoiding
> sed is worth these hassles in working around the implementation-specific
> bugs in the automatic variables. Especially if we have to invoke a shell
> and various commands anyway, how about keeping things as they are? -k

i don't quite buy the argument of "we've got a lot of per-object overhead,
so what's a little bit more".  we should be trying to minimize overhead of
generated code as much as possible.  forking a subshell to fork sed just to
munge a string that we can have make itself generate is pure overhead.

but you're appealing to avoiding hassle.  to that end, i'll point out the
current depdir logic is already in an unhealthy state: we're generating
similar logic 3 times with automake-processed conditionals depending on 3
runtime settings:
?!GENERIC?  %VERBOSE%%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
%-c% -o %OBJ% %SOURCEFLAG%`test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
?!GENERIC?  %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
?GENERIC??!SUBDIROBJ?   %VERBOSE%%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
%-c% -o %OBJ% %SOURCEFLAG%%SOURCE%
?GENERIC??!SUBDIROBJ?   %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
?GENERIC??SUBDIROBJ?%VERBOSE%depbase=`echo %OBJ% | sed 
's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
?GENERIC??SUBDIROBJ?%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o 
%OBJ% %SOURCEFLAG%%SOURCE% &&\
?GENERIC??SUBDIROBJ?$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po

this directly translates to overhead in the generated Makefile.in:
.c.o:
@am__fastdepCC_TRUE@$(AM_V_CC)depbase=`echo $@ | sed 
's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
@am__fastdepCC_TRUE@$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo 
-c -o $@ $< &&\
@am__fastdepCC_TRUE@$(am__mv) $$depbase.Tpo $$depbase.Po
@AMDEP_TRUE@@am__fastdepCC_FALSE@   $(AM_V_CC)source='$<' object='$@' 
libtool=no @AMDEPBACKSLASH@
@AMDEP_TRUE@@am__fastdepCC_FALSE@   DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) 
@AMDEPBACKSLASH@
@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(COMPILE) -c -o $@ $<

switching to make variables will allow us to collapse these.  i'm fairly
confident i can at least collapse the last 5 lines ?GENERIC? into 2 lines.
-mike


signature.asc
Description: PGP signature

[bug#60747] [PATCH] dirstamp: switch to a pattern rule

[Mike Frysinger]

We can leverage $(@D) to generate a single pattern rule for all dirstamp
rules.  This saves many lines in the output -- normally we create 2 rules
(or 6 lines) per subdir, and projects that use subdirs tend to use them
quite a bit.

In the most extreme & unlikely case (1 subdir, no depdir support), the
line count is the same.  In every other case, it's always a win.

Looking at a few real world projects, the line deltas:
* GNU libgloss: +3 -66
* GNU newlib:   +3 -714
* GNU sim:  +3 -138

There shouldn't be any concerns about portability with $(@D) because:
(1) We only generate this rule iff we know the dirstamp is in a subdir
(so we'd never have a case where $(@D) would expand to the cwd)
(2) We already rely on $(@D) in our depdir code, and have since 2014
(the Automake 1.16 release).
---
 bin/automake.in | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/bin/automake.in b/bin/automake.in
index 1c13a3187f46..139d5ad93a9a 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -7893,6 +7893,14 @@ sub require_build_directory
   $directory_map{$directory} = $dirstamp;
   $directory_map{$cdir} = $dirstamp;
 
+  # Generate the pattern rule only once.
+  if (! vardef ('am__dirstamp', TRUE))
+{
+  $output_rules .= ("%/\$(am__dirstamp):\n"
+   . "\t\@\$(MKDIR_P) \$(\@D)\n"
+   . "\t\@: >>\$\@\n");
+}
+
   # Set a variable for the dirstamp basename.
   define_pretty_variable ('am__dirstamp', TRUE, INTERNAL,
  '$(am__leading_dot)dirstamp');
@@ -7900,10 +7908,6 @@ sub require_build_directory
   # Directory must be removed by 'make distclean'.
   $clean_files{$dirstamp} = DIST_CLEAN;
 
-  $output_rules .= ("$dirstamp:\n"
-   . "\t\@\$(MKDIR_P) $directory\n"
-   . "\t\@: >>$dirstamp\n");
-
   return $dirstamp;
 }
 
-- 
2.39.0

[bug#60746] [PATCH] dirstamp: use append too instead of truncate

[Mike Frysinger]

We changed the depfiles logic to use >> (append) instead of > (truncate)
due to it being slightly faster & nicer to the disk.  Do the same with
the dirstamp files as we only need the files to exist -- we don't care
about their content, and we never put anything in them ourselves.  If
someone else were to, we clean them up normally with `make clean`.

Simple test case on my Linux 6.1 w/ext4 on SSD:

@: > foo.txt
for (i = 0; i < 100; ++i) close(open("foo.txt", O_WRONLY|O_CREAT|O_TRUNC, 
0666));
-> 769 msec

@: >>foo.txt
for (i = 0; i < 100; ++i) close(open("foo.txt", O_WRONLY|O_CREAT|O_APPEND, 
0666));
-> 2 sec
---
 bin/automake.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 3069132796f1..1c13a3187f46 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -7902,7 +7902,7 @@ sub require_build_directory
 
   $output_rules .= ("$dirstamp:\n"
. "\t\@\$(MKDIR_P) $directory\n"
-   . "\t\@: > $dirstamp\n");
+   . "\t\@: >>$dirstamp\n");
 
   return $dirstamp;
 }
-- 
2.39.0

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

[Mike Frysinger]

On 04 Jan 2023 21:10, Nick Bowler wrote:
> Except for one minor detail, $(@F) and $(@D) are highly portable.  I
> expect they were in the very first POSIX.2 specs as they predate the
> earliest standards; I believe they first appeared in UNIX System V (ca.
> 1983) and were later added to BSD in 4.3BSD-Reno (ca. 1990).
> 
> The only potential problem I am aware of with these features is one
> implementation (dmake) which does not follow the POSIX rule of excluding
> the trailing slash from the directory part, and (a bit more troublesome)
> will expand $(@D) to the empty string if the directory part is empty,
> instead of . as required by POSIX.  Usually this is not a major issue,
> as writing something like ./$(@D)/$(@F) is usually sufficient to avoid
> any problems with empty $(@D).

thanks ... i vaguely recall seeing a thread somewhere in the last year or
two talking about portable $(@D)/$(@F) issues somewhere which is how i
learned about these in the first place, but i can't seem to locate it, and
the syntax is not conducive to Google searches.  you don't happen to know
what i'm remembering ?  or have a link to some docs about how portable
these vars are ?  i thought it'd be useful to include them in our docs
and/or manual somewhere.

i can build & install dmake easily since someone is maintaining it in GH:
https://github.com/jimjag/dmake
i'll throw some bugs at them :)

> It's worth noting that $(?F), $(?D), $(%F) and $(%D) were never added
> to BSD and as a result are missing from many BSD derivatives.  However,
> these variables are of limited utility and are unlikely to be missed.

that'll be good to note in our docs too

> The $(x:a=b) suffix substitutions are of identical vintage, and as
> far as I know every make supporting file/directory variables also,
> in principle, supports suffix substitution too.  However, there are
> many bugs in real-world implementations of this feature.
> 
> Of particular relevance to this patch: older versions of NetBSD make,
> while they do support suffix substitution, fail to correctly parse
> $(@F:.o=):
> 
>   % cat >Makefile <<'EOF'
> foo/bar.o:
>   echo $(@F:.o=)
> EOF
>   % make
>   echo bar.o.o=)
>   Syntax error: ")" unexpected
>   *** Error code 2
> 
> NetBSD make was widely adopted by other systems, so this particular
> issue may actually be found elsewhere.  This bug was present as recently
> as NetBSD 7.2 (ca. 2018).  Furthermore, old versions of FreeBSD (before
> they ditched their own make in favour of NetBSD's version) also fail to
> correctly handle $(@F:.o=), but in a different way.
> 
> The good news is that these problems can be worked around pretty easily
> simply by using another variable:
> 
>   % cat >Makefile <<'EOF'
> at_f = $(@F)
> foo/bar.o:
>   echo $(at_f:.o=)
> EOF
>   % make
>   echo bar
>   bar
> 
> But this workaround trips over a different suffix substitution bug on
> ULTRIX, which would otherwise work just fine with plain $(@F:.o=).
> Maybe ULTRIX is not worth worrying about these days, but nevertheless,
> it is not too hard to detect and work around both problems in pure
> shell, which should still work to avoid the additional forks/sed,
> maybe something like:
> 
>   % cat >Makefile <<'EOF'
> at_f = $(@F)
> foo/bar.o:
>   a='$(@F:.o=)' b='$(at_f:.o=)'; test x"$$a.o" = x"$(@F)" || a=$$b;\
> echo $$a
> EOF

this is interesting.  we actually have some uses of this already in
the tree.  no one seems to have complained though afaict.

automake-1.13+ has:
lib/am/subdirs.am:AM_RECURSIVE_TARGETS += $(am__recursive_targets:-recursive=)

automake-1.9+ has:
lib/am/texibuild.am:  for f in $@ $@-[0-9] $@-[0-9][0-9] $(@:.info=).i[0-9] 
$(@:.info=).i[0-9][0-9]; do \

dmake is one implementation that fails, and your suggestion doesn't work :/.
$ dmake foo/bar.o
dmake:  Error: -- Incomplete macro expression [)' b='$(at_f:.o=)'; test 
x"$$a.o" = x"$(@F)" || a=$$b;\
echo $$a]

how portable is $() ?  that seems to work in GNU make & dmake.
$ cat Makefile
DEPDIR = ./$(@D)/depdir/$(@F:.o=$())
foo/bar.o:
@echo $(DEPDIR)
$ dmake
./foo//depdir/bar
-mike


signature.asc
Description: PGP signature

[bug#60541] [PATCH] check: drop unused trs_list variable

[Mike Frysinger]

On 04 Jan 2023 16:54, Karl Berry wrote:
> When the code that used this variable was removed, the variable
> itself was left behind.  Clean that up now too.
> * lib/am/check.am: Delete trs_list.
> 
> I can't find when the code using trs_list was removed (no mention in any
> ChangeLog), but indeed, grepping the current sources, I don't find any
> references to it.  So please go ahead and commit this one. --thanks, karl.

`git log -p lib/am/check.am` then search for trs_list.  looks like merge
issues between commit 6c9b282b0a3d7adb3209f74655611e2fdfbf554e and commit
d5443e4c3e6ca109be489bde2e1b4720d69f0029.  this is why i try to avoid
merges myself in general and stick to rebasing -- archaeology is messy.
-mike


signature.asc
Description: PGP signature

[bug#60542] [PATCH/committed] maint: Update files from upstream with 'make fetch'

[Mike Frysinger]

Pulls some 2023 copyright updates.

* lib/config.guess: Update.
* lib/config.sub: Likewise.
* lib/gendocs.sh: Likewise.
* lib/gendocs_template: Likewise.
* lib/gitlog-to-changelog: Likewise.
* lib/gnupload: Likewise.
* lib/texinfo.tex: Likewise.
* lib/update-copyright: Likewise.
---
 lib/config.guess|8 +-
 lib/config.sub  |   27 +-
 lib/gendocs.sh  |8 +-
 lib/gendocs_template|2 +-
 lib/gitlog-to-changelog |2 +-
 lib/gnupload|2 +-
 lib/texinfo.tex | 1330 ++-
 lib/update-copyright|2 +-
 8 files changed, 773 insertions(+), 608 deletions(-)

diff --git a/lib/config.guess b/lib/config.guess
index a419d8643b62..980b02083815 100755
--- a/lib/config.guess
+++ b/lib/config.guess
@@ -4,7 +4,7 @@
 
 # shellcheck disable=SC2006,SC2268 # see below for rationale
 
-timestamp='2022-08-01'
+timestamp='2022-09-17'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -966,6 +966,12 @@ EOF
GNU_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_MACHINE-unknown-$GNU_SYS$GNU_REL-$LIBC
;;
+x86_64:[Mm]anagarm:*:*|i?86:[Mm]anagarm:*:*)
+   GUESS="$UNAME_MACHINE-pc-managarm-mlibc"
+   ;;
+*:[Mm]anagarm:*:*)
+   GUESS="$UNAME_MACHINE-unknown-managarm-mlibc"
+   ;;
 *:Minix:*:*)
GUESS=$UNAME_MACHINE-unknown-minix
;;
diff --git a/lib/config.sub b/lib/config.sub
index fbaa37f2352d..baf1512b3c03 100755
--- a/lib/config.sub
+++ b/lib/config.sub
@@ -4,7 +4,7 @@
 
 # shellcheck disable=SC2006,SC2268 # see below for rationale
 
-timestamp='2022-08-01'
+timestamp='2022-09-17'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -145,7 +145,7 @@ case $1 in
nto-qnx* | linux-* | uclinux-uclibc* \
| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | 
netbsd*-gnu* \
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
-   | storm-chaos* | os2-emx* | rtmk-nova*)
+   | storm-chaos* | os2-emx* | rtmk-nova* | managarm-*)
basic_machine=$field1
basic_os=$maybe_os
;;
@@ -1341,6 +1341,10 @@ EOF
kernel=linux
os=`echo "$basic_os" | sed -e 's|linux|gnu|'`
;;
+   managarm*)
+   kernel=managarm
+   os=`echo "$basic_os" | sed -e 's|managarm|mlibc|'`
+   ;;
*)
kernel=
os=$basic_os
@@ -1754,7 +1758,7 @@ case $os in
 | onefs* | tirtos* | phoenix* | fuchsia* | redox* | bme* \
 | midnightbsd* | amdhsa* | unleashed* | emscripten* | wasi* \
 | nsk* | powerunix* | genode* | zvmoe* | qnx* | emx* | zephyr* \
-| fiwix* )
+| fiwix* | mlibc* )
;;
# This one is extra strict with allowed versions
sco3.2v2 | sco3.2v[4-9]* | sco5v6*)
@@ -1762,6 +1766,9 @@ case $os in
;;
none)
;;
+   kernel* )
+   # Restricted further below
+   ;;
*)
echo Invalid configuration \`"$1"\': OS \`"$os"\' not 
recognized 1>&2
exit 1
@@ -1772,16 +1779,26 @@ esac
 # (given a valid OS), if there is a kernel.
 case $kernel-$os in
linux-gnu* | linux-dietlibc* | linux-android* | linux-newlib* \
-  | linux-musl* | linux-relibc* | linux-uclibc* )
+  | linux-musl* | linux-relibc* | linux-uclibc* | linux-mlibc* 
)
;;
uclinux-uclibc* )
;;
-   -dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* )
+   managarm-mlibc* | managarm-kernel* )
+   ;;
+   -dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* )
# These are just libc implementations, not actual OSes, and thus
# require a kernel.
echo "Invalid configuration \`$1': libc \`$os' needs explicit 
kernel." 1>&2
exit 1
;;
+   -kernel* )
+   echo "Invalid configuration \`$1': \`$os' needs explicit 
kernel." 1>&2
+   exit 1
+   ;;
+   *-kernel* )
+   echo "Invalid configuration \`$1': \`$kernel' does not support 
\`$os'." 1>&2
+   exit 1
+   ;;
kfreebsd*-gnu* | kopensolaris*-gnu*)
;;
vxworks-simlinux | vxworks-simwindows | vxworks-spe)
diff --git a/lib/gendocs.sh b/lib/gendocs.sh
index f6811eea4618..9afe3100e1b9 100755
--- a/lib/gendocs.sh
+++ b/lib/gendocs.sh
@@ -2,9 +2,9 @@
 # gendocs.sh -- generate a GNU manual in many formats.  This script is
 #   mentioned in 

[bug#60541] [PATCH] check: drop unused trs_list variable

[Mike Frysinger]

When the code that used this variable was removed, the variable
itself was left behind.  Clean that up now too.

* lib/am/check.am: Delete trs_list.
---
 lib/am/check.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/am/check.am b/lib/am/check.am
index 6648c011d721..890670d7a178 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -417,11 +417,10 @@ check-TESTS: %CHECK_DEPS%
@$(am__rm_f) $(TEST_SUITE_LOG)
@set +e; $(am__set_TESTS_bases); \
log_list=`for i in $$bases; do echo $$i.log; done`; \
-   trs_list=`for i in $$bases; do echo $$i.trs; done`; \
 ## Remove newlines and normalize whitespace.  Trailing (and possibly
 ## leading) whitespace is known to cause segmentation faults on
 ## Solaris 10 XPG4 make.
-   log_list=`echo $$log_list`; trs_list=`echo $$trs_list`; \
+   log_list=`echo $$log_list`; \
$(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_LOG) TEST_LOGS="$$log_list"; \
 ## Be sure to exit with the proper exit status (automake bug#9245).  See
 ## comments in the recipe of $(TEST_SUITE_LOG) above for more information.
-- 
2.39.0

[bug#60538] [PATCH] rm: convert more cases to am__rm_f

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/10828.

Clean up a few more cases where we were doing `test ... || rm ...` to
avoid calling `rm -f` without arguments by leveraging am__rm_f.  These
were harder to find in the source due to their constructed nature.

The clean programs rules in particular were much more complicated than
they needed to be.  This logic boiled down to two things: delete the
list of programs, and then delete the list without the exeext suffix,
but only if the list of programs is non-empty.

The check-TESTS rule was converted to am__rm_f, but a simplification
was missed where the $list variable is inlined.

* bin/automake.in: Delete test -z logic and always call am__rm_f.
* contrib/check-html.am: Use $(am__rm_f) helper.
* doc/automake.texi: Update examples to match current behavior.
* lib/am/check.am: Inline $list variable.
* lib/am/progs.am: Rewrite rule to use $(am__rm_f).
---
 bin/automake.in   | 7 +--
 contrib/check-html.am | 3 +--
 doc/automake.texi | 6 +++---
 lib/am/check.am   | 4 ++--
 lib/am/progs.am   | 9 ++---
 5 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/bin/automake.in b/bin/automake.in
index c094234bcdad..9b0b52977723 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -4733,12 +4733,7 @@ sub handle_clean
   prog_error 'invalid entry in %clean_files'
unless exists $rms{$when};
 
-  my $rm = "rm -f $file";
-  # If file is a variable, make sure when don't call 'rm -f' without args.
-  $rm ="test -z \"$file\" || $rm"
-   if ($file =~ /^\s*\$(\(.*\)|\{.*\})\s*$/);
-
-  push @{$rms{$when}}, "\t-$rm\n";
+  push @{$rms{$when}}, "\t-\$(am__rm_f) $file\n";
 }
 
   $output_rules .= file_contents
diff --git a/contrib/check-html.am b/contrib/check-html.am
index 56a2ccbff1f9..6764f9aabd83 100644
--- a/contrib/check-html.am
+++ b/contrib/check-html.am
@@ -24,8 +24,7 @@ TEST_SUITE_HTML = $(TEST_SUITE_LOG:.log=.html)
 mostlyclean-local: mostlyclean-check-html
 .PHONY: mostlyclean-check-html
 mostlyclean-check-html:
-## Expand $(TEST_LOGS) only once, to avoid exceeding line length limits.
-   list='$(TEST_LOGS:.log=.html)'; test -z "$$list" || rm -f $$list
+   $(am__rm_f) $(TEST_LOGS:.log=.html)
rm -f $(TEST_SUITE_HTML)
 
 .log.html:
diff --git a/doc/automake.texi b/doc/automake.texi
index 48744e24f3e5..f3b7b86b986e 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7527,8 +7527,8 @@ if you try to run @samp{make foo} explicitly:
 
 @example
 % make clean
-test -z "bindir.h" || rm -f bindir.h
-test -z "foo" || rm -f foo
+rm -f bindir.h
+rm -f foo
 rm -f *.o
 % : > .deps/foo.Po # Suppress previously recorded dependencies
 % make foo
@@ -11316,7 +11316,7 @@ gcc -Wall -o foo main.o func.o
 
 @i{Clean up, so that we can rebuild everything from scratch.}
 % @kbd{make clean}
-test -z "foo" || rm -f foo
+rm -f foo
 rm -f *.o
 
 @i{Silent rules enabled: the output is minimal but informative.  In
diff --git a/lib/am/check.am b/lib/am/check.am
index 6648c011d721..444670db0e7d 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -405,8 +405,8 @@ RECHECK_LOGS = $(TEST_LOGS)
 ## -- ##
 
 check-TESTS: %CHECK_DEPS%
-   @list='$(RECHECK_LOGS)';   $(am__rm_f) $$list
-   @list='$(RECHECK_LOGS:.log=.trs)'; $(am__rm_f) $$list
+   @$(am__rm_f) $(RECHECK_LOGS)
+   @$(am__rm_f) $(RECHECK_LOGS:.log=.trs)
 ## We always have to remove $(TEST_SUITE_LOG), to ensure its rule is run
 ## in any case even in lazy mode: otherwise, if no test needs rerunning,
 ## or a prior run plus reruns all happen within the same timestamp (can
diff --git a/lib/am/progs.am b/lib/am/progs.am
index 753886a31580..0151c263a2b8 100644
--- a/lib/am/progs.am
+++ b/lib/am/progs.am
@@ -114,13 +114,8 @@ clean-%DIR%PROGRAMS:
 ## Cleaning the '_libs/' or '.libs/' directory is done from clean-libtool.
 ## FIXME: In the future (i.e., when it works) it would be nice to delegate
 ## this task to "libtool --mode=clean".
-?LIBTOOL?  @list='$(%DIR%_PROGRAMS)'; test -n "$$list" || exit 0; \
-?LIBTOOL?  echo " rm -f" $$list; \
-?LIBTOOL?  rm -f $$list || exit $$?; \
-?LIBTOOL?  test -n "$(EXEEXT)" || exit 0; \
-?LIBTOOL?  list=`for p in $$list; do echo "$$p"; done | sed 
's/$(EXEEXT)$$//'`; \
-?LIBTOOL?  echo " rm -f" $$list; \
-?LIBTOOL?  rm -f $$list
+?LIBTOOL?  $(am__rm_f) $(%DIR%_PROGRAMS)
+?LIBTOOL?  test -z "$(EXEEXT)" || $(am__rm_f) $(%DIR%_PROGRAMS:$(EXEEXT)=)
 
 
 ## -- ##
-- 
2.39.0

[bug#60536] [PATCH] depend: trim spurious leading tab

[Mike Frysinger]

These vars are replaced with a list of remove commands that are joined
with a \n and each line always has a leading \t inserted.  That means
the literal tab here before the var leads to 2 tabs included in the
output.  While not functionally a problem, it can be a bit confusing
when reading the output as it implies something is amiss.  Trimming
the tab also aligns with the other .am files which don't include it.

* lib/am/depend.am: Delete tab before %DISTRMS%.
---
 lib/am/depend.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/am/depend.am b/lib/am/depend.am
index ecea1fcaa9bc..da8cc6c80f17 100644
--- a/lib/am/depend.am
+++ b/lib/am/depend.am
@@ -31,7 +31,7 @@ am--depfiles: $(am__depfiles_remade)
 ## recursive).
 if %?DISTRMS%
 distclean:
-   %DISTRMS%
+%DISTRMS%
 maintainer-clean:
-   %DISTRMS%
+%DISTRMS%
 endif
-- 
2.39.0

[bug#60535] [PATCH] depend2: switch echo|sed to automatic vars

[Mike Frysinger]

The echo|sed is used to split the dirname & filename so it can insert
$(DEPDIR) in the middle, and then chop the trailing object suffix.  In
the generic case, %OBJ% is $@, so we can leverage the POSIX vars $(@D)
and $(@F) to do the pathname splitting and insert $(DEPDIR) in between.
For chopping the object suffix, we can use the $(xxx:...=...) syntax.
This avoids invoking sed completely.

These dirname/filename vars have been in POSIX since at least 2004.
https://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html
> Each of the internal macros has an alternative form. When an
> uppercase 'D' or 'F' is appended to any of the macros, the
> meaning shall be changed to the directory part for 'D' and
> filename part for 'F'. The directory part is the path prefix
> of the file without a trailing slash; for the current directory,
> the directory part is '.'.

* lib/am/depend2.am: Change echo|sed logic to make variables.
---
 lib/am/depend2.am | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/am/depend2.am b/lib/am/depend2.am
index 507fa40b54a0..87546f9d8274 100644
--- a/lib/am/depend2.am
+++ b/lib/am/depend2.am
@@ -42,7 +42,7 @@ if %FASTDEP%
 ?!GENERIC? %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
 ?GENERIC??!SUBDIROBJ?  %VERBOSE%%COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo 
%-c% -o %OBJ% %SOURCEFLAG%%SOURCE%
 ?GENERIC??!SUBDIROBJ?  %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
-?GENERIC??SUBDIROBJ?   %VERBOSE%depbase=`echo %OBJ% | sed 
's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
+?GENERIC??SUBDIROBJ?   %VERBOSE%depbase='$(@D)/$(DEPDIR)/$(@F:.o=)';\
 ?GENERIC??SUBDIROBJ?   %COMPILE% -MT %OBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% -o 
%OBJ% %SOURCEFLAG%%SOURCE% &&\
 ?GENERIC??SUBDIROBJ?   $(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
 else !%FASTDEP%
@@ -69,7 +69,7 @@ if %FASTDEP%
 ?!GENERIC? %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
 ?GENERIC??!SUBDIROBJ?  %VERBOSE%%COMPILE% -MT %OBJOBJ% -MD -MP -MF 
%DEPBASE%.Tpo %-c% -o %OBJOBJ% %SOURCEFLAG%`$(CYGPATH_W) '%SOURCE%'`
 ?GENERIC??!SUBDIROBJ?  %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
-?GENERIC??SUBDIROBJ?   %VERBOSE%depbase=`echo %OBJ% | sed 
's|[^/]*$$|$(DEPDIR)/&|;s|\.obj$$||'`;\
+?GENERIC??SUBDIROBJ?   %VERBOSE%depbase='$(@D)/$(DEPDIR)/$(@F:.obj=)';\
 ?GENERIC??SUBDIROBJ?   %COMPILE% -MT %OBJOBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% 
-o %OBJOBJ% %SOURCEFLAG%`$(CYGPATH_W) '%SOURCE%'` &&\
 ?GENERIC??SUBDIROBJ?   $(am__mv) %DEPBASE%.Tpo %DEPBASE%.Po
 else !%FASTDEP%
@@ -98,7 +98,7 @@ if %FASTDEP%
 ?!GENERIC? %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Plo
 ?GENERIC??!SUBDIROBJ?  %VERBOSE%%LTCOMPILE% -MT %LTOBJ% -MD -MP -MF 
%DEPBASE%.Tpo %-c% -o %LTOBJ% %SOURCEFLAG%%SOURCE%
 ?GENERIC??!SUBDIROBJ?  %SILENT%$(am__mv) %DEPBASE%.Tpo %DEPBASE%.Plo
-?GENERIC??SUBDIROBJ?   %VERBOSE%depbase=`echo %OBJ% | sed 
's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
+?GENERIC??SUBDIROBJ?   %VERBOSE%depbase='$(@D)/$(DEPDIR)/$(@F:.lo=)';\
 ?GENERIC??SUBDIROBJ?   %LTCOMPILE% -MT %LTOBJ% -MD -MP -MF %DEPBASE%.Tpo %-c% 
-o %LTOBJ% %SOURCEFLAG%%SOURCE% &&\
 ?GENERIC??SUBDIROBJ?   $(am__mv) %DEPBASE%.Tpo %DEPBASE%.Plo
 else !%FASTDEP%
-- 
2.39.0

bug#60508: archive DEPENDENCIES incorrectly depends on ordering

[Mike Frysinger]

i have a project that generates a bunch of arch-specific archives.  i also have
an intermediate archive for holding common objects (so only need to build them
once).  i noticed that while (ab)using LIBADD & OBJECTS variables, Automake
incorrectly omits propagating OBJECTS variables from LIBADD to DEPENDENCIES if
the library using the OBJECTS comes before the library defining the OBJECTS.

attaching a testcase to run against current git that triggers the bug that
hopefully makes it a little clearer:
* libmMID.a defines a bunch of common objects
* libaFIRST.a and libzLAST.a adds libmMID.a's objects to its libadd
* libaFIRST.a's dependency is *missing* the objects, but libzLAST.a has them

$ ./pre-inst-env ./runtest t/ar-dep.sh
...
+ grep _a_DEPENDENCIES = Makefile.in
libaFIRST_a_DEPENDENCIES =
libzLAST_a_DEPENDENCIES = $(libmMID_a_OBJECTS)
+ grep ^libzLAST_a_DEPENDENCIES = $(libmMID_a_OBJECTS) Makefile.in
libzLAST_a_DEPENDENCIES = $(libmMID_a_OBJECTS)
+ grep ^libaFIRSTT_a_DEPENDENCIES = $(libmMID_a_OBJECTS) Makefile.in
+ am_exit_trap 1
...
-mike


ar-dep.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

bug#54363: [PATCH] doc: refer to automake manual in all man pages

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/54363.

There is no "aclocal" manual as it's all integrated into the automake
manual, so have all the help2man calls force automake as the manual.

* doc/local.mk: Use --info-page=automake for man pages.
---
 doc/local.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/local.mk b/doc/local.mk
index 921e22e9ec54..a3503b76ac97 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -37,7 +37,7 @@ EXTRA_DIST += %D%/help2man
 update_mans = \
   $(AM_V_GEN): \
 && $(MKDIR_P) %D% \
-&& AUTOMAKE_HELP2MAN=true ./pre-inst-env $(PERL) $(srcdir)/%D%/help2man 
--output=$@
+&& AUTOMAKE_HELP2MAN=true ./pre-inst-env $(PERL) $(srcdir)/%D%/help2man 
--output=$@ --info-page=automake
 
 %D%/aclocal.1 %D%/automake.1:
$(AM_V_GEN): \
-- 
2.34.1

bug#54363: aclocal info page is not installed

[Mike Frysinger]

On 13 Mar 2022 00:45, Esteve Varela Colominas wrote:
> Running "man aclocal" mentions the availability of a full texinfo manual for 
> the tool at the bottom. However, running "info aclocal" brings up the same 
> man page. I'd like to have this texinfo page shipped alongside the texinfo 
> page that's already installed for the "automake" tool itself.

there is no such "aclocal" manual.  there is only the "automake" manual.
the aclocal man page should point to the automake manual.
-mike


signature.asc
Description: PGP signature

bug#32868: [PATCH v2] m4: rework silent-rules macros to avoid double expansion

[Mike Frysinger]

On 28 Feb 2022 15:58, Karl Berry wrote:
> Fixes automake bug https://bugs.gnu.org/32868.
> 
> Looks fine to me.
> 
> +./configure -C
> +grep '^AM_DEFAULT_VERBOSITY = 1' Makefile
> 
> Good :).
> 
> I remain steadfastly opposed to (ever) changing the default to be silent
> rules, as we've already discussed ad nauseam :).

we shall see :p
-mike


signature.asc
Description: PGP signature

bug#32868: [PATCH v2] m4: rework silent-rules macros to avoid double expansion

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/32868.

The AM_SILENT_RULES macro defines all the silent-rules related setup.
It's also called by users to change the default verbosity level.  This
leads to a quirk where automake calls it, expands the full context,
and then users call it, and it's fully expanded again.

Instead, let's rename AM_SILENT_RULES to _AM_SILENT_RULES and move the
initialization logic to late in the configure stage.  This allows the
user-centric AM_SILENT_RULES call to expand into a single line to set
the default verbosity.

* m4/init.m4: Switch to _AM_SILENT_RULES.
* m4/silent.m4: Rename AM_SILENT_RULES to _AM_SILENT_RULES.  Delay
evaluation of AM_SILENT_RULES to the end.  Define new AM_SILENT_RULES to
set default rules verbosity.
* t/silent-defaults.sh: New tests.
* t/list-of-tests.mk: Add t/silent-defaults.sh.
---
v2
- fix default handling when AM_SILENT_RULES is called before AM_INIT_AUTOMAKE.

 m4/init.m4   |   2 +-
 m4/silent.m4 |  49 -
 t/list-of-tests.mk   |   1 +
 t/silent-defaults.sh | 164 +++
 4 files changed, 196 insertions(+), 20 deletions(-)
 create mode 100644 t/silent-defaults.sh

diff --git a/m4/init.m4 b/m4/init.m4
index f3abf66c6e96..f3c7845bca70 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -134,7 +134,7 @@ if test -z "$CSCOPE"; then
 fi
 AC_SUBST([CSCOPE])
 
-AC_REQUIRE([AM_SILENT_RULES])dnl
+AC_REQUIRE([_AM_SILENT_RULES])dnl
 dnl The testsuite driver may need to know about EXEEXT, so add the
 dnl 'am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen.  This
 dnl macro is hooked onto _AC_COMPILER_EXEEXT early, see below.
diff --git a/m4/silent.m4 b/m4/silent.m4
index b1502ed389b6..d19c56e8ac3b 100644
--- a/m4/silent.m4
+++ b/m4/silent.m4
@@ -5,12 +5,12 @@
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
-# AM_SILENT_RULES([DEFAULT])
-# --
-# Enable less verbose build rules; with the default set to DEFAULT
-# ("yes" being less verbose, "no" or empty being verbose).
-AC_DEFUN([AM_SILENT_RULES],
-[AC_ARG_ENABLE([silent-rules], [dnl
+# _AM_SILENT_RULES
+# 
+# Enable less verbose build rules support.
+AC_DEFUN([_AM_SILENT_RULES],
+[AM_DEFAULT_VERBOSITY=1
+AC_ARG_ENABLE([silent-rules], [dnl
 AS_HELP_STRING(
   [--enable-silent-rules],
   [less verbose build output (undo: "make V=1")])
@@ -18,11 +18,6 @@ AS_HELP_STRING(
   [--disable-silent-rules],
   [verbose build output (undo: "make V=0")])dnl
 ])
-case $enable_silent_rules in @%:@ (((
-  yes) AM_DEFAULT_VERBOSITY=0;;
-   no) AM_DEFAULT_VERBOSITY=1;;
-*) AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1]);;
-esac
 dnl
 dnl A few 'make' implementations (e.g., NonStop OS and NextStep)
 dnl do not support nested variable expansions.
@@ -41,14 +36,6 @@ am__doit:
 else
   am_cv_make_support_nested_variables=no
 fi])
-if test $am_cv_make_support_nested_variables = yes; then
-  dnl Using '$V' instead of '$(V)' breaks IRIX make.
-  AM_V='$(V)'
-  AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
-else
-  AM_V=$AM_DEFAULT_VERBOSITY
-  AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
-fi
 AC_SUBST([AM_V])dnl
 AM_SUBST_NOTMAKE([AM_V])dnl
 AC_SUBST([AM_DEFAULT_V])dnl
@@ -57,4 +44,28 @@ AC_SUBST([AM_DEFAULT_VERBOSITY])dnl
 AM_BACKSLASH='\'
 AC_SUBST([AM_BACKSLASH])dnl
 _AM_SUBST_NOTMAKE([AM_BACKSLASH])dnl
+dnl Delay evaluation of AM_DEFAULT_VERBOSITY to the end to allow multiple calls
+dnl to AM_SILENT_RULES to change the default value.
+AC_CONFIG_COMMANDS_PRE([dnl
+case $enable_silent_rules in @%:@ (((
+  yes) AM_DEFAULT_VERBOSITY=0;;
+   no) AM_DEFAULT_VERBOSITY=1;;
+esac
+if test $am_cv_make_support_nested_variables = yes; then
+  dnl Using '$V' instead of '$(V)' breaks IRIX make.
+  AM_V='$(V)'
+  AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
+else
+  AM_V=$AM_DEFAULT_VERBOSITY
+  AM_DEFAULT_V=$AM_DEFAULT_VERBOSITY
+fi
+])dnl
 ])
+
+# AM_SILENT_RULES([DEFAULT])
+# --
+# Set the default verbosity level to DEFAULT ("yes" being less verbose, "no" or
+# empty being verbose).
+AC_DEFUN([AM_SILENT_RULES],
+[AC_REQUIRE([_AM_SILENT_RULES])
+AM_DEFAULT_VERBOSITY=m4_if([$1], [yes], [0], [1])])
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d959b68db47b..dbfd8d6d1145 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1015,6 +1015,7 @@ t/sanity.sh \
 t/seenc.sh \
 t/silent-c.sh \
 t/silent-cxx.sh \
+t/silent-defaults.sh \
 t/silent-lt.sh \
 t/silent-f77.sh \
 t/silent-f90.sh \
diff --git a/t/silent-defaults.sh b/t/silent-defaults.sh
new file mode 100644
index ..c4cdee548911
--- /dev/null
+++ b/t/silent-defaults.sh
@@ -0,0 +1,164 @@
+#!/bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later 

bug#19418: AC_CONFIG_FILES / stamp-h? problem

[Mike Frysinger]

On 22 Feb 2022 12:53, Jeff Squyres (jsquyres) wrote:
> I'm afraid I can't easily tell.
> 
> It looks like I added a workaround in 
> https://github.com/open-mpi/ompi/commit/40dd4c5b766ff62a681692b1fa6b72a1023fc81f
>  on Dec 20, 2014 (the same day that I initially filed this bug report).
> 
> Half of that workaround was removed in June of 2015 when we stopped embedding 
> a major component 
> (https://github.com/open-mpi/ompi/commit/3e1b85ceb36d952190934e041b8894db98bb38ef);
>  the other half persisted for several years until we changed packaging of 
> another major component in October of 2020 
> (https://github.com/open-mpi/ompi/commit/0e9581d478a20b496c579c9510ea0f3d644a460d).
>   Honestly, I think that when I put in the workaround, we forgot about the 
> issue -- the workaround ultimately disappeared organically over time when we 
> made other major changes to the Open MPI code base.
> 
> So I can't say whether the bug ultimately got fixed in subsequent versions of 
> Automake, whether it was fixed in Open MPI's m4 code, or whether the other 
> major changes in Open MPI made the issue moot.

thanks, that helps.  i can reproduce what you're seeing.
i haven't dug deeper yet to see what's going on.

$ git clone https://github.com/open-mpi/ompi
$ cd ompi
$ git checkout 40dd4c5b766ff62a681692b1fa6b72a1023fc81f
$ WANT_AUTOCONF=2.69 WANT_AUTOMAKE=1.14 autoreconf -vfi
$ ./configure
$ grep ^config_headers= config.status
config_headers="
opal/include/opal_config.h
ompi/include/mpi.h
oshmem/include/shmem.h
opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h
opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h
opal/mca/common/libfabric/libfabric/config.h"
$ grep -A1 ^distclean-hdr Makefile.in
distclean-hdr:
-rm -f \
opal/mca/common/libfabric/libfabric/config.h \
opal/mca/common/libfabric/libfabric/stamp-h4 \
opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h \
opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h5 \
opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h \
opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h6

Automake 1.16 does the same thing.

$ aclocal-1.16 && automake-1.16
$ grep -A1 ^distclean-hdr Makefile.in
distclean-hdr:
-rm -f \
opal/mca/common/libfabric/libfabric/config.h \
opal/mca/common/libfabric/libfabric/stamp-h4 \
opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h \
opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h5 \
opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h \
opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h6
-mike


signature.asc
Description: PGP signature

bug#54063: automake cannot run without generated Texinfo manual

[Mike Frysinger]

On 25 Feb 2022 16:06, Karl Berry wrote:
> Adding a note to the manual is fine, but what would be (much) more
> likely to actually get noticed by users is a runtime warning. What is
> the actual behavior when the basename and @setfilename don't match?

i don't think it's possible to detect from automake, at least at `automake`
time.  the point of Patrice's report is that the sources don't exist when
automake runs, so it's not possible to inspect them.  trying to go further
(having automake attempt to trace partial makefile?  have it generate a
check that runs on the user's system at `make` time?) feels like it's
intruding on the territory of texinfo for no real gain.
-mike


signature.asc
Description: PGP signature

bug#33819: automake-1.16.1 test failures on NetBSD

[Mike Frysinger]

On 24 Feb 2022 11:23, Thomas Klausner wrote:
> FAIL: t/distcheck-override-infodir
> FAIL: t/instdir-texi
> FAIL: t/silent-texi
> FAIL: t/txinfo-builddir
> FAIL: t/txinfo-clean
> FAIL: t/txinfo-info-in-srcdir
> FAIL: t/txinfo-include
> FAIL: t/txinfo-many-output-formats
> FAIL: t/txinfo-many-output-formats-vpath
> FAIL: t/txinfo-no-clutter
> FAIL: t/txinfo-override-texinfo-tex
> FAIL: t/txinfo-subdir-pr343
> FAIL: t/txinfo-vtexi4
> FAIL: t/txinfo-without-info-suffix
> FAIL: t/txinfo23
> FAIL: t/txinfo24
> FAIL: t/txinfo25
> FAIL: t/txinfo28
> FAIL: t/version7
> ...
> distcheck-override-infodir: running texi2dvi --version
> texi2dvi (GNU Texinfo 4.8) 1.34
> ...
> TEXINPUTS="../..:$TEXINPUTS"  MAKEINFO='/bin/sh 
> '/disk/6/archive/foreign/automake-1.16.5/t/distcheck-override-infodir.dir/distcheck-override-infodir-1.0/missing'
>  makeinfo   -I ../..'  texi2dvi  --build-dir=main.t2d -o main.dvi   
> ../../main.texi
> /usr/bin/texi2dvi: Can't use option `--output' with more than one argument.

your texinfo is old & known to be broken.  i thought i saw this recently, but
i can't find the bug/reference.  maybe it's been fixed in git.

> FAIL: t/objc-megademo
> + ./play >got   
> /usr/lib/libobjc.so.4: Trying to call undefined weak symbol 
> `pthread_attr_init'

looks like your host's libobjc.so is broken.  i don't think this is something
we should try and deal with.

> FAIL: t/self-check-dir
> FAIL: t/self-check-dir.tap 1 - testdir has the expected path [unset 
> am_create_testdir]
> FAIL: t/self-check-dir.tap 2 - fully pre-populated testdir [unset 
> am_create_testdir]
> FAIL: t/self-check-dir.tap 3 - testdir has the expected path 
> [am_create_testdir=empty]

not really sure what's going on with these.
-mike


signature.asc
Description: PGP signature

bug#54063: [PATCH] automake: fall back gracefully when texinfo inputs don't exist

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/54063.

The function scanning for @setfilename will fall back to a default
value if the input doesn't have one defined.  But we need to handle
the case where the file doesn't even exist before falling back.

* bin/automake.in: Scan /dev/null for @setfilename if input doesn't exist.
* t/list-of-tests.mk: Add txinfo-no-setfilename-no-inputs.sh.
* t/txinfo-no-setfilename-no-inputs.sh: New test.
---
 bin/automake.in  |  4 +++-
 t/list-of-tests.mk   |  1 +
 t/txinfo-no-setfilename-no-inputs.sh | 31 
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 t/txinfo-no-setfilename-no-inputs.sh

diff --git a/bin/automake.in b/bin/automake.in
index 5eba649d240c..13ad4329caeb 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3062,7 +3062,9 @@ sub scan_texinfo_file
 {
   my ($filename) = @_;
 
-  my $texi = new Automake::XFile "< $filename";
+  # If the source file doesn't exist, we'll fall back below.
+  my $source = -e $filename ? $filename : "/dev/null";
+  my $texi = new Automake::XFile "< $source";
   verb "reading $filename";
 
   my ($outfile, $vfile);
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d959b68db47b..ec08891555e7 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1229,6 +1229,7 @@ t/txinfo-no-extra-dist.sh \
 t/txinfo-no-installinfo.sh \
 t/txinfo-no-repeated-targets.sh \
 t/txinfo-no-setfilename.sh \
+t/txinfo-no-setfilename-no-inputs.sh \
 t/txinfo-other-suffixes.sh \
 t/txinfo-override-infodeps.sh \
 t/txinfo-override-texinfo-tex.sh \
diff --git a/t/txinfo-no-setfilename-no-inputs.sh 
b/t/txinfo-no-setfilename-no-inputs.sh
new file mode 100644
index ..4cedb2f88d81
--- /dev/null
+++ b/t/txinfo-no-setfilename-no-inputs.sh
@@ -0,0 +1,31 @@
+#! /bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Check Texinfo files work without a @setfilename line and no input files.
+# https://bugs.gnu.org/54063
+
+. test-init.sh
+
+cat > Makefile.am << 'END'
+info_TEXINFOS = file.texi
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+grep 'file.info:' Makefile.in
+
+:
-- 
2.34.1

bug#54063: automake cannot run without generated Texinfo manual

[Mike Frysinger]

On 24 Feb 2022 11:19, Patrice Dumas wrote:
> On Thu, Feb 24, 2022 at 01:52:21AM -0500, Mike Frysinger wrote:
> > On 19 Feb 2022 15:03, Patrice Dumas wrote:
> > > In Texinfo, we have a texinfo manual which is automatically generated
> > > from Pod sections from Texinfo perl modules.  When this generated manual
> > > is removed, automake cannot run anymore.  To workaround this issue, we
> > > have a generation of a fake manual that contains only @setfilename 
> > > manual.info 
> > > in the autogen.sh script that can be used to bootstrap some other
> > > autogenerated things, in particular Makefile fragments.  However, this
> > > is not practical, in particular if the generated manual is removed and
> > > the Makefile.am file is modified, one need to redo a fake manual in
> > > order to have things being ok again.
> > > 
> > > It seems to me that one way to avoid the issue would be if automake used
> > > only the texinfo manual name to construct the rules.  It would probably
> > > be a good thing to do irrespective of this issue, as @setfilename is not
> > > as important as it used to be, now it is fully optional, and we probably
> > > should consider as a best practice not to have @setfilename in Texinfo
> > > manuals.
> > > 
> > > The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.
> > 
> > automake already has some fallback logic if @setfilename isn't set -- it
> > uses the basename of the source file and changes .texi to .info.  but it
> > doesn't work if the file doesn't exist.  i think that should be easy to
> > support.
> > 
> > --- a/bin/automake.in
> > +++ b/bin/automake.in
> > @@ -3062,7 +3062,8 @@ sub scan_texinfo_file
> >  {
> >my ($filename) = @_;
> >  
> > -  my $texi = new Automake::XFile "< $filename";
> > +  my $source = -e $filename ? $filename : "/dev/null";
> > +  my $texi = new Automake::XFile "< $source";
> >verb "reading $filename";
> >  
> >my ($outfile, $vfile);
> > 
> > if this is the only thing you need, then i won't think any harder about it.
> 
> I have not tested but it looks good (or a variation with the same effect
> if /dev/null is not portable).

automake already relies on redirecting to /dev/null, so shouldn't be an issue.

> The only issue I see is if after the
> file is generated the @setfilename is not the same as the file base name
> there will be errors.  I do not think that automake should support that
> setup, but maybe it would be good to state it in the documentation.
> Maybe something like:
> 
> "Texinfo files that are generated should have a basename matching
> @setfilename, if there is a @setfilename."

sounds reasonable, but i don't think this is a new issue.
-mike


signature.asc
Description: PGP signature

bug#20713: [PATCH] m4: handle id failures when checking ustar support

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/20713.

If `id` fails, display a specific warning message to the user.

* m4/tar.m4: Check $am_uid & $am_gid if they're unknown.
---
 m4/tar.m4 | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/m4/tar.m4 b/m4/tar.m4
index 7e3df4f98e1c..8f4d2f21394b 100644
--- a/m4/tar.m4
+++ b/m4/tar.m4
@@ -46,15 +46,19 @@ m4_if([$1], [v7],
   am_uid=`id -u || echo unknown`
   am_gid=`id -g || echo unknown`
   AC_MSG_CHECKING([whether UID '$am_uid' is supported by ustar format])
-  if test $am_uid -le $am_max_uid; then
- AC_MSG_RESULT([yes])
+  if test x$am_uid = xunknown; then
+AC_MSG_WARN([ancient id detected; assuming current UID is ok, but 
dist-ustar might not work])
+  elif test $am_uid -le $am_max_uid; then
+AC_MSG_RESULT([yes])
   else
- AC_MSG_RESULT([no])
- _am_tools=none
+AC_MSG_RESULT([no])
+_am_tools=none
   fi
   AC_MSG_CHECKING([whether GID '$am_gid' is supported by ustar format])
-  if test $am_gid -le $am_max_gid; then
- AC_MSG_RESULT([yes])
+  if test x$gm_gid = xunknown; then
+AC_MSG_WARN([ancient id detected; assuming current GID is ok, but 
dist-ustar might not work])
+  elif test $am_gid -le $am_max_gid; then
+AC_MSG_RESULT([yes])
   else
 AC_MSG_RESULT([no])
 _am_tools=none
-- 
2.34.1

bug#54063: automake cannot run without generated Texinfo manual

[Mike Frysinger]

On 19 Feb 2022 15:03, Patrice Dumas wrote:
> In Texinfo, we have a texinfo manual which is automatically generated
> from Pod sections from Texinfo perl modules.  When this generated manual
> is removed, automake cannot run anymore.  To workaround this issue, we
> have a generation of a fake manual that contains only @setfilename 
> manual.info 
> in the autogen.sh script that can be used to bootstrap some other
> autogenerated things, in particular Makefile fragments.  However, this
> is not practical, in particular if the generated manual is removed and
> the Makefile.am file is modified, one need to redo a fake manual in
> order to have things being ok again.
> 
> It seems to me that one way to avoid the issue would be if automake used
> only the texinfo manual name to construct the rules.  It would probably
> be a good thing to do irrespective of this issue, as @setfilename is not
> as important as it used to be, now it is fully optional, and we probably
> should consider as a best practice not to have @setfilename in Texinfo
> manuals.
> 
> The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.

automake already has some fallback logic if @setfilename isn't set -- it
uses the basename of the source file and changes .texi to .info.  but it
doesn't work if the file doesn't exist.  i think that should be easy to
support.

--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3062,7 +3062,8 @@ sub scan_texinfo_file
 {
   my ($filename) = @_;
 
-  my $texi = new Automake::XFile "< $filename";
+  my $source = -e $filename ? $filename : "/dev/null";
+  my $texi = new Automake::XFile "< $source";
   verb "reading $filename";
 
   my ($outfile, $vfile);

if this is the only thing you need, then i won't think any harder about it.
-mike


signature.asc
Description: PGP signature

bug#33819: automake-1.16.1 test failures on NetBSD

[Mike Frysinger]

On 21 Dec 2018 10:46, Thomas Klausner wrote:
> When running the self tests on NetBSD (8.99.27/amd64) with perl
> 5.28.1, I see 26 test failures.
> 
> The log is attached.

from the log:
> FAIL: t/instspc

this seems to be due to install-sh being used over normal mkdir -p.  but
that should be fine by itself ... it seems you have a weird /bin/sh ?  it
is causing errors that shouldn't happen.  the output makes it look like
things are underquoted, but i checked the script and ran it locally, and
it looks fine to me.

> FAIL: t/instspc.tap 17 - percent in builddir
> FAIL: t/instspc.tap 18 - percent in destdir
> FAIL: t/instspc.tap 32 - star in destdir
> FAIL: t/instspc.tap 79 - quadrigraph4 in builddir
> FAIL: t/instspc.tap 80 - quadrigraph4 in destdir
> FAIL: t/instspc.tap 81 - a_b in builddir
> FAIL: t/instspc.tap 82 - a_b in destdir
> FAIL: t/instspc.tap 83 - a__b in builddir
> FAIL: t/instspc.tap 84 - a__b in destdir
> FAIL: t/instspc.tap 92 - miscglob1 in destdir

these are all some variation of:

> + 
> DESTDIR=/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent
>  file='./%' make test-inst
> ../install-sh -c -d 
> '/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent/%-prefix/foo'
> mkdir: 
> /scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-percent/%-prefix/foo:
>  No such file or directory
> *** Error code 1

> FAIL: t/instspc.tap 59 - space in builddir
> FAIL: t/instspc.tap 60 - space in destdir
> FAIL: t/instspc.tap 61 - tab in builddir
> FAIL: t/instspc.tap 62 - tab in destdir

these are all some variation of:

> + 
> DESTDIR=/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-space 
> file='./ ' make test-inst
> ../install-sh -c -d 
> '/scratch/devel/automake/work/automake-1.16.1/t/instspc.dir/dest-space/ 
> -prefix/foo'
> mkdir: unknown option -- r
> usage: mkdir [-p] [-m mode] dirname ...
> chmod: unknown option -- p
> Usage: chmod [-R [-H | -L | -P]] [-fh] mode file ...
> chmod [-R [-H | -L | -P]] [-fh] --reference=rfile file ...
> mkdir: unknown option -- r
> usage: mkdir [-p] [-m mode] dirname ...
> *** Error code 1

> FAIL: t/install-sh-unittests
> FAIL: t/instfail
> FAIL: t/self-check-dir
> FAIL: t/self-check-dir.tap 1 - testdir has the expected path [unset 
> am_create_testdir]
> FAIL: t/self-check-dir.tap 2 - fully pre-populated testdir [unset 
> am_create_testdir]
> FAIL: t/self-check-dir.tap 3 - testdir has the expected path 
> [am_create_testdir=empty]
> FAIL: t/self-check-dir.tap 5 - do not create nor chdir in testdir 
> [am_create_testdir=no]
> FAIL: t/install-sh-unittests-w

more install-sh weirdness

> FAIL: t/dist-with-unreadable-makefile-fails
> FAIL: t/instfail-info
> FAIL: t/instmany
> FAIL: t/instmany-mans
> FAIL: t/test-trs-recover2

not sure
-mike


signature.asc
Description: PGP signature

bug#34151: GNU Automake 1.16.1 FAIL: 4 on Solaris 10 SPARC

[Mike Frysinger]

On 20 Jan 2019 22:00, Dennis Clarke wrote:
> The usual. Nothing new here.  Four failed tests on ye old Solaris 10 
> sparc with Oracle Studio 12.6 compiler tools.
> 
> test-suite.log attached.

from the log:

> FAIL: t/dist-formats
> + bzip2 -d parallel-compression-1.0.tar.bz2
> bzip2: Caught a SIGSEGV or SIGBUS whilst decompressing.
> FAIL: t/dist-formats.tap 58 - gzip+bzip2+xz [check .tar.bz2 tarball]

pretty sure there's nothing we can do about this.  going to ignore it.

> FAIL: t/instmany-python
> FAIL t/instmany-python.sh (exit status: 1)
> /usr/local/build/automake-1.16.1_SunOS5.10_sparc64vii+.001/t/instmany-python.dir/x-bin/my-install:
>  safe command line limit of 2500 characters exceeded

i would guess this is the same as https://bugs.gnu.org/53340 which is now
fixed in the tree.

> FAIL: t/lex-clean-cxx
> FAIL t/lex-clean-cxx.sh (exit status: 2)
> FAIL: t/lex-depend-cxx
> FAIL t/lex-depend-cxx.sh (exit status: 2)
> /bin/bash ./ylwrap parsefoo.lxx lex.yy.c parsefoo.cxx -- lex
> source='parsefoo.cxx' object='parsefoo.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/bash ./depcomp \
> /opt/developerstudio12.6/bin/CC -DPACKAGE_NAME=\"lex-clean-cxx\" 
> -DPACKAGE_TARNAME=\"lex-clean-cxx\" -DPACKAGE_VERSION=\"1.0\" 
> -DPACKAGE_STRING=\"lex-clean-cxx\ 1.0\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE_URL=\"\" -DPACKAGE=\"lex-clean-cxx\" -DVERSION=\"1.0\" -I.   
> -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
> -D_TS_ERRNO  -m64 -xarch=sparc -dalign -erroff=%none -errtags=yes 
> -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xdepend=no 
> -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs -c -o parsefoo.o 
> parsefoo.cxx
> "parsefoo.cxx", line 84: Error: yylex() was declared before with a different 
> language.
> 1 Error(s) detected.
> gmake: *** [Makefile:491: parsefoo.o] Error 2

this is interesting.  the tests do:
#define YY_DECL int yylex (void)
extern "C" YY_DECL;

which seems your compiler cannot handle for some reason.
-mike


signature.asc
Description: PGP signature

bug#32800: [PATCH/committed] tests: make silent-custom regex a little more robust

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/32800.

Have the regex match the entire path with word boundaries on both
sides.  This should reduce false positives when the full cwd happens
to match parent directories.

* t/silent-custom.sh: Update the header output regex.
---
 t/silent-custom.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/silent-custom.sh b/t/silent-custom.sh
index 01cf464b99eb..977255b1312e 100644
--- a/t/silent-custom.sh
+++ b/t/silent-custom.sh
@@ -74,7 +74,7 @@ do_check ()
 $FGREP 'cp ' output && exit 1
 $FGREP 'generate-header' output && exit 1
 $FGREP 'rm -f' output && exit 1
-grep '[012]\.h' output && exit 1
+grep '\bsub/[012]\.h\b' output && exit 1
 grep '^ XGENfoo$' output
 grep '^ GEN \[headers\]$' output
   else
-- 
2.34.1

bug#7610: [PATCH v2 committed] automake: support embedded \# in variable appends

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/7610.

Use of \# is not portable.  POSIX does not provide any way of retaining
the # marker in variables.  There is wide spread support for \# though
in GNU & BSD Make implementations.

Today, with plain variable assignments, Automake leaves the line alone:
  foo = blah\#blah
This will leave it to the implementation to decide what to do.  But if
you try to append to it, Automake follows POSIX and strips it:
  foo = blah\#blah
  foo += what
  -> foo = blah\ what

Instead, let's issue a portability warning whenever \# is used, even if
it isn't being appended, and do not strip the \# when appending.  Now:
  foo = blah\#blah
  foo += what
  -> warning: escaping \# comment markers is not portable
  -> foo = blah\#blah what

* NEWS: Mention change in \# handling.
* lib/Automake/VarDef.pm: Do not strip # if escaped.
* lib/Automake/Variable.pm: Warn if \# is used.
* t/comment12.sh: New test.
* t/comments-escaped-in-var.sh: New test.
* t/list-of-tests.mk: Add comment12.sh & comments-escaped-in-var.sh.
---
v2
- had to adjust the regex slightly to handle comments at the start of vars,
  and add a new test to catch variations on it

 NEWS |  3 +++
 lib/Automake/VarDef.pm   |  2 +-
 lib/Automake/Variable.pm |  3 +++
 t/comment12.sh   | 44 +
 t/comments-escaped-in-var.sh | 47 
 t/list-of-tests.mk   |  2 ++
 6 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 t/comment12.sh
 create mode 100644 t/comments-escaped-in-var.sh

diff --git a/NEWS b/NEWS
index 512cdecd0cc5..665d8329d667 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,9 @@ New in 1.17:
 drop support for them has been reversed.  The ACCEPT_INFERIOR_RM_PROGRAM
 setting no longer exists.
 
+  - Variables using escaped \# will trigger portability warnings, but be
+retained when appended.  GNU Make & BSD Makes are known to support it.
+
 * Obsolescent features:
 
   - py-compile no longer supports Python 0.x or 1.x versions.  Python 2.0,
diff --git a/lib/Automake/VarDef.pm b/lib/Automake/VarDef.pm
index 59af4036b35f..00d694a6fbda 100644
--- a/lib/Automake/VarDef.pm
+++ b/lib/Automake/VarDef.pm
@@ -188,7 +188,7 @@ sub append ($$$)
   #   VAR = foo # com bar
   # Furthermore keeping '#' would not be portable if the variable is
   # output on multiple lines.
-  $val =~ s/ ?#.*//;
+  $val =~ s/ ?(^|[^\\])#.*/$1/;
   # Insert a separator, if required.
   $val .= ' ' if $val;
   $self->{'value'} = $val . $value;
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index 4f6a88d61c5c..1269d5d9f40e 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -857,6 +857,9 @@ sub define ()
   msg ('portability', $where, "':='-style assignments are not portable")
 if $type eq ':';
 
+  msg ('portability', $where, "escaping \\# comment markers is not portable")
+if index ($value, '\#') != -1;
+
   check_variable_expansions ($value, $where);
 
   # If there's a comment, make sure it is \n-terminated.
diff --git a/t/comment12.sh b/t/comment12.sh
new file mode 100644
index ..e98159e40f3e
--- /dev/null
+++ b/t/comment12.sh
@@ -0,0 +1,44 @@
+#! /bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Make sure that earlier comments are consumed when appending to it.
+
+. test-init.sh
+
+cat > Makefile.am << 'END'
+VAR1=# eat this comment
+VAR2 =# eat this comment
+VAR3 = # eat this comment
+VAR4 = # eat this comment
+VAR5 = val# eat this comment
+VAR6 = val # eat this comment
+
+VAR1 += val
+VAR2 += val
+VAR3 += val
+VAR4 += val
+VAR5 +=
+VAR6 +=
+END
+
+$ACLOCAL
+$AUTOMAKE
+
+# For debugging.
+grep '^VAR' Makefile.in
+
+count=`grep '^VAR. = val$' Makefile.in | wc -l`
+[ $count -eq 6 ]
diff --git a/t/comments-escaped-in-var.sh b/t/comments-escaped-in-var.sh
new file mode 100644
index ..e06c3f359b68
--- /dev/null
+++ b/t/comments-escaped-in-var.sh
@@ -0,0 +1,47 @@
+#! /bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope 

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

[Mike Frysinger]

On 23 Feb 2022 01:12, Mike Frysinger wrote:
> my inclination is to introduce two new variables that would be used for 
> libtool
> & non-libtool, and only when compiling.
> * xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override
>   the compiler on a per-program basis
> * xxx_COMPILEFLAGS: appended only to compile calls so it can override all the
>   variables that are shared with other commands

having glanced through the implementation a bit, i don't know that i'll try
to implement this myself, at least any time soon.  this is heavily in the
perl side of things, and i'm not really versed in it.
-mike


signature.asc
Description: PGP signature

bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

[Mike Frysinger]

On 17 Feb 2022 16:33, Karl Berry wrote:
> Hi Damian - thanks for the report.
> 
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> $(AM_CFLAGS) $(CFLAGS)
> ...
> `libtool` has a command line option, `-no-suppress` ...
> 
> Well, the immediate answer would apparently be to add yet another
> variable after the --mode=compile, say LTMODEOPTS for the sake of
> argument (have to think about the name), so the output is
> 
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> $(LIBTOOLFLAGS) --mode=compile $(LTMODEOPTS) $(CC) ...

to clarify, Damian isn't saying it has to be between --mode=compile & $(CC).
in fact, pretty sure this doesn't work as libtool expects the argv to be the
arguments right after --mode=compile.

$ libtool --tag=CC --mode=compile -no-suppress gcc test.c -c -o test.o
Usage: /usr/bin/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool:   error: unrecognised option: '-no-suppress'

the right command line is:
$ libtool --tag=CC --mode=compile gcc test.c -c -o test.o -no-suppress

so i think we can reframe the request as: Automake offers no way of specifying
flags that are only used at compile time.  breaking down LTCOMPILE (for C):
* $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) 
--mode=compile:
  doesn't help as comes before $(CC) and we need flags to be after
* $(CC): used for preprocessing & compiling, and linking, and default for
  linking via `CCLD = $(CC)`
* $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS): used for
  preprocessing (dep generation, etc...) and compiling
* $(AM_CFLAGS) $(CFLAGS): used for preprocessing, compiling, and linking

if we look at the linking phase specifically, it's possible to put libtool
flags into xxx_LDFLAGS.  this is good, and what we already document+recommend.

my inclination is to introduce two new variables that would be used for libtool
& non-libtool, and only when compiling.
* xxx_COMPILE: to provide parity with existing xxx_LINK setting -- override
  the compiler on a per-program basis
* xxx_COMPILEFLAGS: appended only to compile calls so it can override all the
  variables that are shared with other commands

my only gripe is the lack of parity between other stages from a naming pov,
but i think we just have to swallow this pill.  most flags are based on the
language selection rather than the phase (e.g. CFLAGS is for C language and
is used for preprocessing, compiling, and linking C code).  LDFLAGS is only
for linking -- it's language independent.  if we added xxx_LINKFLAGS, it
would serve the same exact purpose as xxx_LDFLAGS, so doesn't add a whole
lot of value.
-mike


signature.asc
Description: PGP signature

[bug#54120] [PATCH] manual: mention LT_INIT

[Mike Frysinger]

The AC_PROG_LIBTOOL macro name is the old/deprecated one, so include
LT_INIT here too to avoid confusing people who have switched.

* doc/automake.texi: Add LT_INIT after AC_PROG_LIBTOOL.
---
 doc/automake.texi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/automake.texi b/doc/automake.texi
index b13f96809ce3..3101ae144fdc 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3152,6 +3152,7 @@ distributed with Autoconf version 2.58 and later.  
@xref{Particular
 Programs, , Particular Program Checks, autoconf, The Autoconf Manual}.
 
 @item AC_PROG_LIBTOOL
+@itemx LT_INIT
 Automake will turn on processing for @command{libtool} (@pxref{Top, ,
 Introduction, libtool, The Libtool Manual}).
 
-- 
2.34.1

bug#20713: aclocal/tar.m4 and solaris 5.10

[Mike Frysinger]

On 22 Feb 2022 16:29, Karl Berry wrote:
> The "test" item, most of the way down in the "Limitations of Shell
> Builtins" node of the Autoconf manual, reports a lot of the things that
> have led to the common forms/workarounds.
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#Limitations-of-Builtins

thanks, this is what i was looking for.  maybe i should actually read the
autotools manuals one day instead of using them purely as references.

> the reason your system hit this code path
> 
> I was not running make dist. I was just running configure on Solaris 5.10.
> As far as I can recall.

i'm sure that was the case (i.e. you ran configure but never dist).  but if
we can only test tools during configure, and the dist step requires results
from that probing, but we're not allowed to probe dist-specific tools during
configure, then we're in a bit of a catch-22.

i'm not aware of other parts being delayed/split based on their usage.  for
example, if i just `make && make install`, one could argue that configure
checking for deps/behaviors that only matter to `make check` are incorrect.

off the top of my head, i think Automake's `missing` tool is about the only
exception to this approach/rule, and even then, that's pretty thin -- it's
only seeing if a specific program exists, not whether it supports specific
functionality or is otherwise buggy.

>it can be helpful when you're hacking on a system and want to pull
>the state back out.
> 
> Personally, I would never trust make dist not to alter the state
> that it was supposedly snapshotting.

to be clear, when i said "state", i meant "the source code".  obviously i
wouldn't expect (or want) `make dist` to pick up any intermediates or build
outputs.  i'm not sure along what lines your distrust of dist flows, but i
will point out that this logic is entirely Automake's, so it would be a
little unusable if you consider `make dist` unreliable as a maintainer of
Automake :).
-mike


signature.asc
Description: PGP signature

bug#20713: aclocal/tar.m4 and solaris 5.10

[Mike Frysinger]

On 21 Feb 2022 16:26, Karl Berry wrote:
> should we change "unknown" to $GID & $UID respectively ?
> 
> I guess it couldn't hurt, although I doubt it makes any difference in
> practice.

i feel like you just accidentally wrote Automake's motto :p

> if test $am_uid = "unknown"; then
> 
> Don't we usually avoid quoting constant strings? I.e.:
> if test "$am_uid" = unknown; then

tbh, i have no idea what the quoting style/preference is in the GNU world,
if there actually is one.  i know i see plenty of underquoting, and plenty
of odd `test` styles that aren't well documented (like using the "x" prefix
to avoid testing empty strings).

>   AC_MSG_WARN([ancient id detected; assuming current UID is ok, but 
> dist-ustar might not work])
> 
> "Might"? Either it works or it doesn't? Anyway, who ever uses ustar?
> Never seen it.

we won't know whether it works until we actually try to create an archive.
and depending on the system, that might be too late (see below).

> Anyway, seems like such a warning "might" be useful when producing an
> archive with automake (running make dist), but not when running
> configure. When merely doing "./configure && make", ustar is irrelevant.

sure, but we don't probe tools during `make dist`, we do it during configure

> Anyway #2, I think the chances of someone wanting to produce a ustar
> archive on a system with old id is zero.
> 
> Thus I suggest just fixing the syntax stuff and letting it go at that. 

ustar might not be the most common nowadays.  i think there's merit to
issuing a warning so we aren't in the situation of people reporting bugs
that `make dist` threw a weird error they don't understand, and if their
system was in such a bad state, why weren't they warned about it ?  in
fact, isn't that what led to these checks in the first place ?  we have
reports from users:
https://bugs.gnu.org/8343
https://bugs.gnu.org/13588

> the point of the checks isn't just to annoy the user.
> 
> No :)? That's what it seems like. Helpful to the package developer;
> annoyance to the configure user. -k

configure user can (re)create dist tarballs too.  not the common flow, but
it can be helpful when you're hacking on a system and want to pull the state
back out.  or when trying to comply with the GPL requirements :).

the reason your system hit this code path is because it wasn't able to handle
the formats earlier in the list (gnutar in this case).
-mike


signature.asc
Description: PGP signature

bug#17614: parallel compilation fails

[Mike Frysinger]

On 21 Feb 2022 12:15, Peter Johansson wrote:
> On 25/1/22 16:24, Mike Frysinger wrote:
> > On 19 Jan 2022 18:32, Peter Johansson wrote:
> >> On 19/1/22 18:10, Mike Frysinger wrote:
> >>> assuming it still fails with Automake 1.16 ...
> >>
> >> I'll test when I'm out of this semi-lockdown and have access to a
> >> computer with more CPUs.
> >>
> >>> can you link to the project for us to take a look ?
> >> Tar file is available from here
> >>
> >> https://sourceforge.net/projects/libyat/
> >>
> >> and subversion repo from here if that's preferable
> >>
> >> https://dev.thep.lu.se/yat/svn/trunk
> > i grabbed the 0.19 release.  perhaps unsurprising, nothing stood out to me
> > related to the error above.  you didn't have any recursive makes or any code
> > that seemed to override the dep generation or create conflicting outputs.
> >
> > if you can reproduce it, get a full log and send it over, and include the
> > config.log file i think.  something like `make -O -j... >& log`.
> >
> > the error you quoted is part of automake's dependency generation.  it's very
> > weird that you'd get an error about .Tpo & .Plo being the same file when the
> > rule that creates them creates the .Tpo then moves it to .Plo.  there is no
> > place where we ever write to .Plo otherwise.
> 
> I've tried this now and in short I cannot reproduce it. I tried with 
> Automake 1.13 now (bcs it's what available by default) and ran both on 
> current code and an older branch, but nothing that looks like this. Many 
> things have changed since 2014 when this was filed and I think for 
> example that the file system was much slower back then. I suspect that 
> the problem was that the same file was compiled twice, but since I can't 
> reproduce it, it's impossible to determine whether it was due to 
> problematic Makefile.am, generated Makefile, or possibly behaviour of 
> make, so if not already closed, please close this and I'll report back 
> if something similar returns.

np.  feel free to ping/reopen if something does turn up.
-mike


signature.asc
Description: PGP signature

bug#20713: aclocal/tar.m4 and solaris 5.10

[Mike Frysinger]

On Mon, 01 Jun 2015 21:02:32 +, Karl Berry wrote:
> Running a configure script on solaris 5.10 generated with automake-1.15,
> I got these errors about id, which being pre-POSIX, does not support -u:
>
>   id: illegal option -- u
>   Usage: id [-ap] [user]
>   id: illegal option -- g
>   Usage: id [-ap] [user]
>   checking whether UID 'unknown' is supported by ustar format... 
> ./configure: line 4190: test: unknown: integer expression expected
>   no
>   checking whether GID 'unknown' is supported by ustar format... 
> ./configure: line 4200: test: unknown: integer expression expected
>   no
>
> It comes from aclocal-1.15/tar.m4, which says:
>   ... Errors in the 'id' calls
>   # below are definitely unexpected, so allow the users to see them
>
> Well, they are not "unexpected" on this system, so it's not especially
> helpful to see them.  Still, I suppose it is not worth worrying about.
> And I'm sure it is not worth parsing the output of this old id (with no
> args passed) to get the info, but for the record, that would be:
> uid=1053(karl) gid=1053(karl)
>
> But what I do think would make sense is to avoid the subsequent error of
> using a numeric test expression on a known non-numeric (the string
> "unknown") when id fails.  After all, that much is tar.m4's own doing.
> Perhaps simply change
>   if test $am_uid -le $am_max_uid; then
> to
>   if test $am_uid != unknown && test $am_uid -le $am_max_uid; then
> (and ditto gid).

should we change "unknown" to $GID & $UID respectively ?

if the `id` call fails, seems like we could at least still issue a warning.
the point of the checks isn't just to annoy the user.

if test $am_uid = "unknown"; then
  AC_MSG_WARN([ancient id detected; assuming current UID is ok, but dist-ustar 
might not work])
elif test $am_uid -le $am_max_uid; then
  AC_MSG_RESULT([yes])
else
  AC_MSG_RESULT([no])
  _am_tools=none
fi
-mike

bug#20300: [PATCH] automake: allow required files to be in subdirs

[Mike Frysinger]

Fixes automake bug https://bugs.gnu.org/20300.

The internal method for caching path lookups expects the $filename to
only be a filename.  If it's actually a subdir/file itself, then the
cache logic gets confused, and it never matches.  This manifests as
AC_REQUIRE_AUX_FILE([subdir/file]) claiming that the subdir/file path
doesn't exist even when it does.

Before we process any required files, since we already construct the
full path locally, reset the dir & file inputs to the final values.

* bin/automake.in: Split dir & file name back out from the constructed
required file path.
* t/auxdir-subsubdir.sh: New test.
* t/list-of-tests.mk: Add t/auxdir-subsubdir.sh.
---
 bin/automake.in   |  7 +++
 t/auxdir-subsubdir.sh | 39 +++
 t/list-of-tests.mk|  1 +
 3 files changed, 47 insertions(+)
 create mode 100644 t/auxdir-subsubdir.sh

diff --git a/bin/automake.in b/bin/automake.in
index 5a151455019e..5eba649d240c 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -7628,6 +7628,13 @@ sub required_file_check_or_copy
   my ($where, $dir, $file) = @_;
 
   my $fullfile = "$dir/$file";
+  # In cases where $file is actually a subdir/filename, split the full path 
back
+  # into dir & file names.  The FileUtils (e.g. dir_has_case_matching_file) do
+  # not handle this scenario at all and expect $file to only be a filename.
+  # https://bugs.gnu.org/20300
+  $dir = dirname ($fullfile);
+  $file = basename ($fullfile);
+
   my $found_it = 0;
   my $dangling_sym = 0;
 
diff --git a/t/auxdir-subsubdir.sh b/t/auxdir-subsubdir.sh
new file mode 100644
index ..21880f23591f
--- /dev/null
+++ b/t/auxdir-subsubdir.sh
@@ -0,0 +1,39 @@
+#! /bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Make sure auxdir with subdir aux files works.
+
+. test-init.sh
+
+cat > configure.ac build-aux/subdir/file
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d8e50b080166..85de422193a0 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -188,6 +188,7 @@ t/auxdir-computed.tap \
 t/auxdir-misplaced.sh \
 t/auxdir-nonexistent.sh \
 t/auxdir-pr19311.sh \
+t/auxdir-subsubdir.sh \
 t/auxdir-unportable.tap \
 t/backcompat.sh \
 t/backcompat2.sh \
-- 
2.34.1