[PATCH] aclocal: add m4 search path info to --help

[Mike Frysinger]

Add a short summary to --help of the current paths that will be
searched.  Make sure to omit this from the man page when running
help2man since pre-inst-env specifically clears some and others
to the current build directory.

* bin/aclocal.in: Include m4 search paths in usage.
* doc/local.mk: Run help2man with AUTOMAKE_HELP2MAN=true.
---
 bin/aclocal.in | 20 +++-
 doc/local.mk   |  2 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/bin/aclocal.in b/bin/aclocal.in
index 857e85308cd3..36651c8c2882 100644
--- a/bin/aclocal.in
+++ b/bin/aclocal.in
@@ -1044,12 +1044,30 @@ Options:
   third-party m4 files, then exit
   --verbose don't be silent
   --version print version number, then exit
-  -W, --warnings=CATEGORY   report the warnings falling in CATEGORY
+  -W, --warnings=CATEGORY   report the warnings falling in CATEGORY,
+  defaults to $WARNINGS
+
 EOF
 
   print Automake::ChannelDefs::usage (), "\n";
 
+  # This output depends on the current environment, and when generating the man
+  # pages during Automake compilation, the environment is set to local values.
+  # So don't include it in the installed man page.
+  if (!$ENV{AUTOMAKE_HELP2MAN}) {
+print <<"EOF";
+
+Current m4 search paths (in order):
+  -I dirs:  @user_includes
+  --automake-acdir: @automake_includes
+  \$ACLOCAL_AUTOMAKE_DIR:$ENV{"ACLOCAL_AUTOMAKE_DIR"}
+  --system-acdir:   @system_includes
+  \$ACLOCAL_PATH:$ENV{"ACLOCAL_PATH"}
+EOF
+  }
+
   print <<'EOF';
+
 Report bugs to <@PACKAGE_BUGREPORT@>.
 GNU Automake home page: <@PACKAGE_URL@>.
 General help using GNU software: .
diff --git a/doc/local.mk b/doc/local.mk
index 06c78823a574..921e22e9ec54 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% \
-&& ./pre-inst-env $(PERL) $(srcdir)/%D%/help2man --output=$@
+&& AUTOMAKE_HELP2MAN=true ./pre-inst-env $(PERL) $(srcdir)/%D%/help2man 
--output=$@
 
 %D%/aclocal.1 %D%/automake.1:
$(AM_V_GEN): \
-- 
2.34.1

Re: adding a command line option for ACLOCAL_PATH-type search paths

[Nick Bowler]

On 19/01/2022, Mike Frysinger  wrote:
> the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
> but a bit unwieldy as an env var.  any reason we can't add a command line
> option for this ?  call it --aclocal-path ?  or --extra-system-acdir ?
> or some other other boring name ?
>
> for context, when cross-compiling, autotools (i.e. automake) tend to be
> installed in the system (i.e. /usr/), while all the libraries & macros
> being built against are found in a separate sysroot (e.g. ~/sysroot/).
> we want to insert that ~/sysroot/usr/share/aclocal path after the set
> of -I flags from the package, but before /usr/share/aclocal.
> -mike

FWIW another option besides the env var is to create a third
directory, and put a file called "dirlist" in it with two lines:

  /path/to/sysroot/usr/share/aclocal
  /usr/share/aclocal

Then you can use the --system-acdir=/path/to/that/directory option
for aclocal to have it search both places.

Cheers,
  Nick

Re: adding a command line option for ACLOCAL_PATH-type search paths

[Mike Frysinger]

On 19 Jan 2022 16:05, Karl Berry wrote:
> Hi Mike,
> 
> the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
> but a bit unwieldy as an env var.  any reason we can't add a command line
> option for this ?  
> 
> Seems like a fine idea to me.
> 
> call it --aclocal-path ?  or --extra-system-acdir ?
> 
> Reading the doc, my hunch is to call it --aclocal-path and make the
> semantics of its argument be exactly the same as $ACLOCAL_PATH. Wdyt?

i was leaning towards it behaving like -I -- it takes a single path, not a
colon-delimited list of paths.  not sure if that's what you meant by "be
exactly the same as $ACLOCAL_PATH".

otherwise, yeah, it'd be the same.

> But if both are set, should the --aclocal-path argument replace
> $ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure.

i don't have an opinion.  if we have another scenario that does this, i'd
be fine to use that so we're consistent.  Peter's point about autoconf &
$WARNING handling seems like a good enough reason to do it that way.

> By the way, would it be feasible to have --help show the actual values
> for --automake-acdir and --system-acdir? It is far from obvious.

sounds like a good idea.  i'll poke a little.
-mike


signature.asc
Description: PGP signature

bug#38043: Python version language support

[Karl Berry]

Automake guarantees releases will support all Python versions that
are still supported by the Python project at the time of the
Automake release.  Support for EOL versions of Python are not
guaranteed, but will be considered as long as it is not onerous to
do so, and there are large supported distros including them.  If you
need to support older Python versions, please use a previous
Automake release.

That sounds like a sensible approach to me. Jim?

* we update the manual to state clearly:
  * Python 2.7 & 3.4 - 3.10 are fully supported
  * Python 2.0 - 2.6 & 3.0 - 3.3 should work, but are not tested
  * Python <2.0 do not work are not supported at all

I agree it would be useful to be explicit about Python versions in the
manual.

Personally, I would find it impossible to track what Python versions
require what and what we support, but as long as you can make the needed
updates to the manual at each release time (something to be added to the
release list ... Jim?), sounds good to me.

I would add that we don't object to installing patches for older
versions, or for whatever other reason, as long as the patches are
understandable and maintainable. In practice, that is what we (I) do
now.  I have little understanding of (or interest in) Python, but if
people send usable patches, I'm happy to install them. What any given
patch might mean for version support, I don't even begin to figure out.

Thanks,
Karl

Re: multiple online manual versions

[Karl Berry]

* the current page, but with an entry/link like "For older manuals,
  please see this index."

Agreed this is preferable. Not a fan of the gcc index page.

changes to the manual the rename or reorder chapters, we're breaking
those historical links.

Reordering isn't a problem; that doesn't break links. Renaming nodes is
what breaks links. And the answer is, 1) don't do it, and 2) if you feel
you simply must, leave an @anchor behind, and then existing links will
not be broken.  Anyway, the manual hardly changes nowadays, so it's not
an issue in practice.

To me, the redirection to a versioned url a la autoconf often leads to
the wrong behavior in the other direction: typically people want to link
or refer to the current version of node Foobar (whatever version it
might be), but it's too much trouble to do when you end up getting
redirected. So it doesn't happen, and then X years now people still
think autoconf-2.68, for example, is current because that's what the
link say. (Rather like bugs.gnu.org/ being preferred, but since that
redirects, hardly anyone uses it and it's just manual labor to do
so. But I digress.)


any other manual/ access would redirect to the latest version.
that way we don't break links already out in the wild.

Agreed we certainly must not break existing links. But I'd rather have a
copy as the unversioned/canonical page than forced redirection in all
cases.  Both canonical and versioned urls are useful.

https://www.gnu.org/software/automake/manual/1.15/
https://www.gnu.org/software/automake/manual/1.16/
(or if you prefer, 1.15.x and such)

If not publishing all versions, it would seem better to me to publish
the latest version of the manual for any given 1.x, not the first
version. I.e., 1.13.4, 1.14.1, 1.15.1, 1.16.5. I don't see that there's
anything especially magical about the "non-dot" releases like 1.15,
although I have no objection to publishing those too. --thanks, karl.

Re: adding a command line option for ACLOCAL_PATH-type search paths

[Peter Johansson]

Hi Karl,

On 20/1/22 09:05, Karl Berry wrote:

But if both are set, should the --aclocal-path argument replace
$ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure.


FWIW, in autoconf the commandline -W takes precedence over environment 
variable WARNINGS


https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#autoconf-Invocation


Cheers,

Peter

Re: adding a command line option for ACLOCAL_PATH-type search paths

[Karl Berry]

Hi Mike,

the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
but a bit unwieldy as an env var.  any reason we can't add a command line
option for this ?  

Seems like a fine idea to me.

call it --aclocal-path ?  or --extra-system-acdir ?

Reading the doc, my hunch is to call it --aclocal-path and make the
semantics of its argument be exactly the same as $ACLOCAL_PATH. Wdyt?

But if both are set, should the --aclocal-path argument replace
$ACLOCAL_PATH, or augment it (earlier of course)? I'm not sure.


By the way, would it be feasible to have --help show the actual values
for --automake-acdir and --system-acdir? It is far from obvious.
--thanks, karl.

[PATCH] progs, libs: support _RANLIB overrides

[Mike Frysinger]

Much like we have per-target support for _AR and _LINK, add an _RANLIB
override too.  This allows selection of specific ranlib tools in case
a non-standard archiver tool was forced.

* bin/automake.in: Check for _RANLIB per-target settings.
* doc/automake.texi: Document _RANLIB override.
* lib/am/library.am: Change $(RANLIB) to $(%XLIBRARY%_RANLIB).
* t/ranlib_override.sh: New test.
* NEWS: Mention new feature.
---
 NEWS |  8 
 bin/automake.in  |  6 +-
 doc/automake.texi|  5 +
 lib/am/library.am|  2 +-
 t/ranlib_override.sh | 49 
 5 files changed, 68 insertions(+), 2 deletions(-)
 create mode 100644 t/ranlib_override.sh

diff --git a/NEWS b/NEWS
index 121fe820eeef..79a81f22e92f 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,14 @@ please see NEWS-2.0 and start following the advice there now.
 
 
 
+New in 1.17:
+
+* New features added
+
+  - RANLIB may be overridden on a per-target basis.
+
+
+
 New in 1.16.5:
 
 * Bugs fixed
diff --git a/bin/automake.in b/bin/automake.in
index 28e0fe67233b..58b589495e39 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -2704,12 +2704,16 @@ sub handle_libraries ()
   # Canonicalize names and check for misspellings.
   my $xlib = check_canonical_spelling ($onelib, '_LIBADD', '_SOURCES',
'_OBJECTS', '_DEPENDENCIES',
-   '_AR');
+   '_AR', '_RANLIB');
 
   if (! var ($xlib . '_AR'))
{
  define_variable ($xlib . '_AR', '$(AR) $(ARFLAGS)', $where);
}
+  if (! var ($xlib . '_RANLIB'))
+   {
+ define_variable ($xlib . '_RANLIB', '$(RANLIB)', $where);
+   }
 
   # Generate support for conditional object inclusion in
   # libraries.
diff --git a/doc/automake.texi b/doc/automake.texi
index 9916a41d4b79..67827cf8698a 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5811,6 +5811,11 @@ compiler likes this variable set like so:
 libmaude_a_AR = $(CXX) -ar -o
 @end example
 
+@item maude_RANLIB
+A static library's index is updated by default by invoking @samp{$(RANLIB)}
+followed by the name of the library.  You can override this by setting the
+@code{_RANLIB} variable.
+
 @item maude_LIBADD
 Extra objects can be added to a @emph{library} using the @code{_LIBADD}
 variable.  For instance, this should be used for objects determined by
diff --git a/lib/am/library.am b/lib/am/library.am
index 06af1d16821e..effaf39f93f5 100644
--- a/lib/am/library.am
+++ b/lib/am/library.am
@@ -17,4 +17,4 @@
 %LIBRARY%: $(%XLIBRARY%_OBJECTS) $(%XLIBRARY%_DEPENDENCIES) 
$(EXTRA_%XLIBRARY%_DEPENDENCIES) %DIRSTAMP%
%SILENT%-rm -f %LIBRARY%
%VERBOSE%$(%XLIBRARY%_AR) %LIBRARY% $(%XLIBRARY%_OBJECTS) 
$(%XLIBRARY%_LIBADD)
-   %SILENT%$(RANLIB) %LIBRARY%
+   %SILENT%$(%XLIBRARY%_RANLIB) %LIBRARY%
diff --git a/t/ranlib_override.sh b/t/ranlib_override.sh
new file mode 100644
index ..100e3734bc53
--- /dev/null
+++ b/t/ranlib_override.sh
@@ -0,0 +1,49 @@
+#! /bin/sh
+# Copyright (C) 2009-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 3 of the License, 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 .
+
+# Test to make sure _RANLIB variables are detected and used as documented.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_AR
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+EXTRA_LIBRARIES = libfoo.a libbar.a
+libfoo_a_SOURCES = foo.c
+libfoo_a_RANLIB = $(RANLIB)
+libbar_a_SOURCES = bar.c
+END
+
+$ACLOCAL
+$AUTOMAKE -a
+
+# We should use libfoo_a_RANLIB not RANLIB.
+grep '.\$(libfoo_a_RANLIB) *libfoo.a' Makefile.in
+grep '.\$(RANLIB).*libfoo.a' Makefile.in && exit 1
+
+# We should use default RANLIB.
+grep '^ *libbar_a_RANLIB *=.*\$(RANLIB)' Makefile.in
+
+# Silent make rules should use AM_V_at as they're silenced.
+grep '.\$(AM_V_at)\$(libfoo_a_RANLIB)' Makefile.in
+grep '.\$(AM_V_at)\$(libbar_a_RANLIB)' Makefile.in
+
+exit 0
-- 
2.33.0

[PATCH] tests: add _AR override coverage

[Mike Frysinger]

There were no tests for per-target _AR settings, so add some.

* t/ar_override.sh: New test.
---
 t/ar_override.sh | 50 
 1 file changed, 50 insertions(+)
 create mode 100644 t/ar_override.sh

diff --git a/t/ar_override.sh b/t/ar_override.sh
new file mode 100644
index ..4f4024989aec
--- /dev/null
+++ b/t/ar_override.sh
@@ -0,0 +1,50 @@
+#! /bin/sh
+# Copyright (C) 2009-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 3 of the License, 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 .
+
+# Test to make sure _AR variables are detected and used as documented.
+
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_AR
+AC_PROG_RANLIB
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+EXTRA_LIBRARIES = libfoo.a libbar.a
+libfoo_a_SOURCES = foo.c
+libfoo_a_AR = $(AR)
+libbar_a_SOURCES = bar.c
+END
+
+$ACLOCAL
+$AUTOMAKE -a
+
+# We should use libfoo_a_AR not AR ARFLAGS.
+grep '.\$(libfoo_a_AR) *libfoo.a' Makefile.in
+grep '.\$(AR).*libfoo.a' Makefile.in && exit 1
+grep '.\$(ARFLAGS).*libfoo.a' Makefile.in && exit 1
+grep '^ *libfoo_a_AR *=.*\$(ARFLAGS)' Makefile.in && exit 1
+
+# We should use default AR ARFLAGS.
+grep '^ *libbar_a_AR *=.*\$(ARFLAGS)' Makefile.in
+
+# Silent make rules should use AM_V_AR.
+grep '.\$(AM_V_AR)\$(libbar_a_AR)' Makefile.in
+
+exit 0
-- 
2.33.0

bug#14245: [PATCH] tests: add coverage for nobase_ and dist_ prefixes

[Mike Frysinger]

>From automake bug https://bugs.gnu.org/14245.

We have tests that check nobase_ and nodist_ interaction, but not
nobase_ and dist_.  We had a report against automake 1.12 that this
combo did not work.  It seems to work now, but lets include a test
to make sure we don't regress.

Based on Daiki Ueno's example, but fixed up to pass against master.

* t/nobase-dist.sh: New test.
---
 t/nobase-dist.sh | 67 
 1 file changed, 67 insertions(+)
 create mode 100644 t/nobase-dist.sh

diff --git a/t/nobase-dist.sh b/t/nobase-dist.sh
new file mode 100644
index ..b2ead50ee9da
--- /dev/null
+++ b/t/nobase-dist.sh
@@ -0,0 +1,67 @@
+#! /bin/sh
+# Copyright (C) 2011-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 .
+
+# Interaction of 'nobase_' and 'dist_' prefixes.
+
+. test-init.sh
+
+cat >> configure.ac <<'EOF'
+AC_OUTPUT
+EOF
+
+cat > Makefile.am <<'EOF'
+foodir = $(prefix)/foo
+
+bardir = $(prefix)/bar
+
+sub/nodist.dat:
+   $(MKDIR_P) sub
+   : > $@
+
+nobase_foo_DATA = sub/nodist.dat
+nobase_dist_foo_DATA = sub/dist.dat
+
+dist_bar_DATA = sub/base.dat
+nobase_dist_bar_DATA = sub/nobase.dat
+
+CLEANFILES = sub/nodist.dat
+EOF
+
+mkdir sub
+
+: > sub/dist.dat
+: > sub/nobase.dat
+: > sub/base.dat
+
+rm -f install-sh
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE -a
+./configure --prefix "$(pwd)/inst"
+
+$MAKE
+$MAKE install
+
+test -f inst/foo/sub/nodist.dat
+test -f inst/foo/sub/dist.dat
+
+test -f inst/bar/sub/nobase.dat
+test -f inst/bar/base.dat
+
+$MAKE distcheck
+
+:
-- 
2.33.0

bug#17614: parallel compilation fails

[Peter Johansson]

Hi Mike,

On 19/1/22 18:10, Mike Frysinger wrote:

retitle 17614 parallel compilation fails: mv: 
yat/statistics/.deps/Percentiler.Tpo and yat/statistics/.deps/Percentiler.Tpo 
are the same file
tag 17614 = moreinfo
thankyou

On Wed, 28 May 2014 14:52:21 +1000, Peter Johansson wrote:

I have a project with a libtool archive built from many source files.
When I build with 'make -j40' I get error message

mv: `yat/statistics/.deps/Percentiler.Tpo' and
`yat/statistics/.deps/Percentiler.Plo' are the same file
make[1]: *** [yat/statistics/Percentiler.lo] Error 1


Looks like some kind of race problem, but I cannot see anything wrong in
the Makefile. Is this a known problem? If not let me know what would be
useful.

The Makefile is generated with Automake 1.14

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


Thanks,

Peter

bug#14245: nobase_foo_DATA vs nobase_dist_foo_DATA

[Mike Frysinger]

close 14245 !
thankyou

On Tue, 23 Apr 2013 15:30:17 +0900, Daiki Ueno wrote:
> With Automake master and 1.12.2, if Makefile.am has:
>
>   nobase_foo_DATA = sub/nodist.dat
>   nobase_dist_foo_DATA = sub/dist.dat
>
> sub/dist.dat is not packed in the distribution.  I doubt this is a bug,
> but the opposite use of dist_ and nobase_:
>
>   dist_bar_DATA = sub/base.dat
>   nobase_dist_bar_DATA = sub/nobase.dat
>
> works just fine.
>
> I'm attaching a test case.

thanks for the test case.  it's slightly incomplete and fails because distcheck
can't find sub/nodist.dat to install (which makes sense as it wasn't included
in the tarball).  but that was trivial to resolve with your test case, and i'm
guessing it was failing sooner for you.

which is my long winded way of saying i can't reproduce the bug with automake
1.16.  i'm going to mark this done on the assumption something/someone fixed
the bug.  but i'll update your test and include it to make sure we keep working.

specifically, looking at the tarball produced by `make dist`, i see:
nobase-dist-1.0/sub/
nobase-dist-1.0/sub/nobase.dat
nobase-dist-1.0/sub/base.dat
nobase-dist-1.0/sub/dist.dat
-mike

bug#31262: makefile = 1.14, when I have 1.15

[Mike Frysinger]

archive 31262
thankyou

i think we'll just archive this as both infeasible & out-of-scope
-mike

bug#17614: parallel compilation fails

[Mike Frysinger]

retitle 17614 parallel compilation fails: mv: 
yat/statistics/.deps/Percentiler.Tpo and yat/statistics/.deps/Percentiler.Tpo 
are the same file
tag 17614 = moreinfo
thankyou

On Wed, 28 May 2014 14:52:21 +1000, Peter Johansson wrote:
> I have a project with a libtool archive built from many source files. 
> When I build with 'make -j40' I get error message
>
> mv: `yat/statistics/.deps/Percentiler.Tpo' and 
> `yat/statistics/.deps/Percentiler.Plo' are the same file
> make[1]: *** [yat/statistics/Percentiler.lo] Error 1
>
>
> Looks like some kind of race problem, but I cannot see anything wrong in 
> the Makefile. Is this a known problem? If not let me know what would be 
> useful.
>
> The Makefile is generated with Automake 1.14

assuming it still fails with Automake 1.16 ...

can you link to the project for us to take a look ?  it's very hard for us to
guess at what's going wrong, and would be a lot easier if we could repro on
our own systems.
-mike