bug#15114: "make dist" clobbers "configure" (regression?)

2013-08-17 Thread automake
Dear automake maintainers,

I recently upgraded Automake from 1.11.1 to 1.14 using MacPorts on my
mac running OSX 10.6.

Since the upgrade the script "configure" in my project gets clobbered in
the distdir when running "make dist": size 0, executable bit removed.
All other files seem in order.

The sources for this project are in: https://github.com/knz/mgsim

I checked the clobbering by setting "am__remove_distdir=:" and looking
at the directory before archiving so tar is not the culprit.

Also the problem persists with "am__skip_mode_fix=:".

Could you advise as to how to investigate this problem further?

Many thanks





bug#43945: Support thumbv7a architecture

2020-10-12 Thread KOLANICH via Bug reports for Automake
Hello. When I crosscompiled some app I had to patch some file generated by 
autoreconf -i, where I have to add thumbv7[arm] (using the analogy to 
armv7[arm] already present there) there. Though I haven't found the source file 
corresponding to it, so no patches. Feel free to fix yourselves.





bug#51225: Possible bug in python.m4, automake 1.16.4+

2021-10-15 Thread bluemoon via Bug reports for Automake

Hi,

in commit

https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670

line 160 of python.m4

you changed the sed command so that am_cv_python_pythondir does not
contain the content of $PYTHON_PREFIX anymore but the variable name 
$PYTHON_PREFIX. The same with $PYTHON_EXEC_PREFIX a couple of lines below.


For reference:

@@ -157,13 +224,13 @@ sys.stdout.write(sitedir)"`
  case $am_cv_python_pythondir in
  $am_py_prefix*)
am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
-   am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed 
"s,^$am__strip_prefix,$PYTHON_PREFIX,"`
+   am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed 
"s,^$am__strip_prefix,\\${PYTHON_PREFIX},"`

;;
  *)
case $am_py_prefix in
  /usr|/System*) ;;
  *)
-	 
am_cv_python_pythondir=$PYTHON_PREFIX/lib/python$PYTHON_VERSION/site-packages
+	 
am_cv_python_pythondir="\${PYTHON_PREFIX}/lib/python$PYTHON_VERSION/site-packages"

  ;;
esac
;;

However, this change leads to pkg-config .pc files containing the
variable name $PYTHON_PREFIX, not its content, which makes third
packages fail to build because $PYTHON_PREFIX cannot be resolved.

For example xcb-proto.pc, a dependency of polybar, has the line

pythondir=${pc_sysrootdir}${PYTHON_PREFIX}/lib/python3.10/site-packages

but it should be

pythondir=${pc_sysrootdir}${prefix}/lib/python3.10/site-packages

which can be achieved when reverting the double backslash like

--- a/m4/python.m4  2021-10-04 04:51:12.0 +0200
+++ b/m4/python.m4  2021-10-15 08:38:08.575081215 +0200
@@ -263,7 +263,7 @@
case $am_cv_python_pythondir in
$am_py_prefix*)
  am__strip_prefix=`echo "$am_py_prefix" | sed 's|.|.|g'`
- am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed 
"s,^$am__strip_prefix,\\${PYTHON_PREFIX},"`
+ am_cv_python_pythondir=`echo "$am_cv_python_pythondir" | sed 
"s,^$am__strip_prefix,${PYTHON_PREFIX},"`

  ;;
*)
  case $am_py_prefix in
@@ -305,7 +305,7 @@
case $am_cv_python_pyexecdir in
$am_py_exec_prefix*)
  am__strip_prefix=`echo "$am_py_exec_prefix" | sed 's|.|.|g'`
- am_cv_python_pyexecdir=`echo "$am_cv_python_pyexecdir" | sed 
"s,^$am__strip_prefix,\\${PYTHON_EXEC_PREFIX},"`
+ am_cv_python_pyexecdir=`echo "$am_cv_python_pyexecdir" | sed 
"s,^$am__strip_prefix,${PYTHON_EXEC_PREFIX},"`

  ;;
*)
  case $am_py_exec_prefix in


Using --with-python-sys-prefix makes no difference.

So is the double backslash intented or by accident?
Or am I completely misunderstanding something?


Thank you!





bug#51225: Possible bug in python.m4, automake 1.16.4+

2021-10-17 Thread bluemoon via Bug reports for Automake

Am 17.10.21 um 04:30 schrieb Joshua Root:

On 2021-10-17 12:32 , Karl Berry wrote:
 
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670 



 However, this change leads to pkg-config .pc files containing the
 variable name $PYTHON_PREFIX, not its content

I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.

Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.


The documentation mentions in several places that the variables set by 
Automake are only really designed to be used in the Makefiles that it 
generates. Using AC_SUBST to directly substitute them into other kinds 
of files comes with the risk of exactly this kind of thing happening.


You could equally complain that some variables you want to use in the 
.pc file are defined in terms of $prefix; except it just happens that 
most .pc files already contain a prefix variable, so it works.


As Karl alluded to, if you want the fully expanded path, the .pc file 
needs to be generated by make, not configure. If you don't do it that 
way, the way these Makefile variables are defined will change and break 
your non-Makefiles sometimes.


- Josh


Thank you for your explanation! So I guess xcb-proto needs to be fixed 
then. I’ll report it to them. But I have a strong feeling that, as you 
explained, this problem will come up again as more and more projects 
start using automake >=1.16.4.






bug#51225: Possible bug in python.m4, automake 1.16.4+

2021-10-17 Thread bluemoon via Bug reports for Automake

Am 17.10.21 um 04:30 schrieb Joshua Root:

On 2021-10-17 12:32 , Karl Berry wrote:
 
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670 



 However, this change leads to pkg-config .pc files containing the
 variable name $PYTHON_PREFIX, not its content

I admit I didn't test much explicitly, but my understanding was that the
use of ${PYTHON_PREFIX} in various places instead of its value was
intentional, to allow for overriding at make time.

Thus, whatever the process is for creating .pc files, I guess it
may need to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.


The documentation mentions in several places that the variables set by 
Automake are only really designed to be used in the Makefiles that it 
generates. Using AC_SUBST to directly substitute them into other kinds 
of files comes with the risk of exactly this kind of thing happening.


You could equally complain that some variables you want to use in the 
.pc file are defined in terms of $prefix; except it just happens that 
most .pc files already contain a prefix variable, so it works.


As Karl alluded to, if you want the fully expanded path, the .pc file 
needs to be generated by make, not configure. If you don't do it that 
way, the way these Makefile variables are defined will change and break 
your non-Makefiles sometimes.


- Josh


@Josh sorry, but only just now did I see you already sent a patch to 
xcb-proto. This does solve the issue for me.


Anyway, thanks again to both of you! :)





bug#57404: (no subject)

2022-08-25 Thread alexei_sylver1--- via Bug reports for Automake

Hi!
I download  https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz
and compiled it. I have several tests failed in `make check ` command
Most of them are marked with # TODO long-standing limitation
but there are several other failed tests
 
I configured installation with non-statndard path /tools/automake-1.16.5,
but I don’t belived this caused fails
 
my script:
wget https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz tar xvf 
automake-1.16.5.tar.gz
ls auto*
cd automake-1.16.5/
./configure --prefix=/tools/automake-1.16.5
make
make install
 
make check output:
SKIP: t/get-sysconf.sh
XFAIL: t/pm/Cond2.pl
XFAIL: t/pm/Cond3.pl
XFAIL: t/pm/DisjCon2.pl
XFAIL: t/pm/DisjCon3.pl
XFAIL: t/pm/Version2.pl
XFAIL: t/pm/Version3.pl
XFAIL: t/instspc.tap 1 - squote in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 2 - squote in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 3 - dquote in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 4 - dquote in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 5 - bquote in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 6 - bquote in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 7 - sharp in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 8 - sharp in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 9 - dollar in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 10 - dollar in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 13 - bslash in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 15 - ampersand in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 63 - linefeed in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 64 - linefeed in destdir # TODO long-standing limitation
XFAIL: t/instspc.tap 71 - quadrigraph0 in builddir # TODO long-standing 
limitation
XFAIL: t/instspc.tap 85 - a_lf_b in builddir # TODO long-standing limitation
XFAIL: t/instspc.tap 86 - a_lf_b in destdir # TODO long-standing limitation
SKIP: t/aclocal-macrodir.tap 7 # SKIP autoconf is too old (AC_CONFIG_MACRO_DIRS 
not defined)
SKIP: t/aclocal-macrodirs.tap 15 # SKIP autoconf is too old 
(AC_CONFIG_MACRO_DIRS not defined)
XFAIL: t/all.sh
amhello-cross-compile: skipped test: required program 'i586-mingw32msvc-gcc' 
not available
SKIP: t/amhello-cross-compile.sh
ar-lib5a: skipped test: Microsoft 'lib' utility not available
SKIP: t/ar-lib5a.sh
XFAIL: t/auxdir-computed.tap 2 - automake -a # TODO long-standing limitation
XFAIL: t/auxdir-computed.tap 3 - automake # TODO long-standing limitation
auxdir-pr19311: skipped test: this test passes with autoconf-2.69d and newer
SKIP: t/auxdir-pr19311.sh
canon7: skipped test: required program 'libtool' not available
SKIP: t/canon7.sh
check12: skipped test: DejaGnu is not available
SKIP: t/check12.sh
color-tests2: skipped test: requires a working expect program
SKIP: t/color-tests2.sh
compile4: skipped test: Microsoft C compiler 'cl' not available
SKIP: t/compile4.sh
compile5: skipped test: target OS is not MinGW
SKIP: t/compile5.sh
compile7: skipped test: Intel C compiler 'icl' not available
SKIP: t/compile7.sh
XFAIL: t/cond17.sh
SKIP: t/cscope.tap 3 # SKIP no proper cscope program available
SKIP: t/cscope.tap 4 # SKIP no proper cscope program available
SKIP: t/cscope.tap 5 # SKIP no proper cscope program available
SKIP: t/cscope.tap 9 # SKIP no proper cscope program available
SKIP: t/cscope.tap 10 # SKIP no proper cscope program available
SKIP: t/cscope.tap 11 # SKIP no proper cscope program available
SKIP: t/cscope.tap 15 # SKIP no proper cscope program available
SKIP: t/cscope.tap 16 # SKIP no proper cscope program available
SKIP: t/cscope.tap 17 # SKIP no proper cscope program available
cscope3: skipped test: required program 'cscope' not available
SKIP: t/cscope3.sh
dejagnu3: skipped test: DejaGnu is not available
SKIP: t/dejagnu3.sh
dejagnu4: skipped test: DejaGnu is not available
SKIP: t/dejagnu4.sh
dejagnu5: skipped test: DejaGnu is not available
SKIP: t/dejagnu5.sh
dejagnu6: skipped test: DejaGnu is not available
SKIP: t/dejagnu6.sh
dejagnu7: skipped test: DejaGnu is not available
SKIP: t/dejagnu7.sh
dejagnu-absolute-builddir: skipped test: DejaGnu is not available
SKIP: t/dejagnu-absolute-builddir.sh
dejagnu-relative-srcdir: skipped test: DejaGnu is not available
SKIP: t/dejagnu-relative-srcdir.sh
dejagnu-siteexp-extend: skipped test: DejaGnu is not available
SKIP: t/dejagnu-siteexp-extend.sh
SKIP: t/dist-formats.tap 9 - 'make dist-lzip' work by default # SKIP 'lzip' not 
available
SKIP: t/dist-formats.tap 17 - 'make dist-zstd' work by default # SKIP 'zstd' 
not available
SKIP: t/dist-formats.tap 40 - am=no-dist-gzip ac=dist-lzip [distcheck] # SKIP 
'lzip' not available
SKIP: t/dist-formats.tap 41 - am=no-dist-gzip ac=dist-lzip [ark-exists] # SKIP 
'lzip' not available
S

bug#64968: automake --version isn't work

2023-07-31 Thread 874882199--- via Bug reports for Automake
In Docker(in the vmware ubunt also has the problem):
 
Environment:
 
Ubuntu 20.04 5.15.0-78-generic.
 
Automake1.4 from ftp://gcc.gnu.org/pub/java/automake-gcj-1.4.tar.gz.
 
 
 
root@576a62413a36:~/automakeOut# automake --version
 
syntax error at /usr/local/bin/automake line 932, near "$name ("
 
syntax error at /usr/local/bin/automake line 1095, near "$subr ("
 
BEGIN not safe after errors--compilation aborted at /usr/local/bin/automake 
line 3287.
 
 
 
And the readme don??t have anything about this ,so I sent the message.

bug#68141: automake-1.16j on Ubuntu

2024-01-01 Thread Bogdan via Bug reports for Automake

Karl Berry , 2023-12-31 00:37:

 FAIL: t/python-prefix

 Log file is attached.

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

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



 Hi.

 From what I last read, the "new" paths were some new invention of
Ubuntu/Debian(?) and not some general change in Python 3.10, so we
can't simply base on the version number, I guess.
 This test (and maybe other?) already has some path-related 'make'
targets, so apparently, such were needed (if not here, than in other
tests, where I wrote such targets myself), and apparently it's not
just a matter of simply changing the hardcoded "site-packages" to
hardcoded "dist-packages", but some more tweaking needs to be done.
 I don't have Python 3.10 or Ubuntu/Debian, but maybe I'll play with
this anyway, I'll see. It may be a bit of a guessing game with more
than 1 attempt. Fortunately, it's "just" the test that's failing
because the paths are different and it's e.g. not Automake failing to
install files at all.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






bug#64837: [bug#54412] [bug#64837] Fix Python on Debian

2024-01-09 Thread Bogdan via Bug reports for Automake

Hello.

 Referring to the discussion related to the upcoming release, I
confirm defect #64837 on Debian GNU/Linux 12 (bookworm) and I confirm
that the last patch in #54412 (the one attached in the defect in
Message#14 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#14,
not the one inlined) fixes the issue.
 I'm also attaching a "double-safe" version, with a simple try-except
added, falling back to the old default, just in case. Also tested,
also fixes the issue.
 You can apply whichever you choose.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From 9eb9f92cd45f2f85e50ff1367319b3af8e5106b9 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 9 Jan 2024 22:31:57 +0100
Subject: [PATCH] Double-safe patch for Python 3.10

---
 m4/python.m4 | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/m4/python.m4 b/m4/python.m4
index 8d4e4d215..c97ffd203 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -256,7 +256,17 @@ except ImportError:
am_cv_python_pythondir=`$PYTHON -c "
 $am_python_setup_sysconfig
 if can_use_sysconfig:
-  sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
+  try:
+if hasattr(sysconfig, 'get_default_scheme'):
+  scheme = sysconfig.get_default_scheme()
+else:
+  scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+  # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+  scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('purelib', scheme, vars={'base':'$am_py_prefix'})
+  except:
+sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
 else:
   from distutils import sysconfig
   sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')
@@ -298,7 +308,17 @@ sys.stdout.write(sitedir)"`
am_cv_python_pyexecdir=`$PYTHON -c "
 $am_python_setup_sysconfig
 if can_use_sysconfig:
-  sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
+  try:
+if hasattr(sysconfig, 'get_default_scheme'):
+  scheme = sysconfig.get_default_scheme()
+else:
+  scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+  # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+  scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('platlib', scheme, vars={'platbase':'$am_py_exec_prefix'})
+  except:
+sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
 else:
   from distutils import sysconfig
   sitedir = sysconfig.get_python_lib(1, 0, prefix='$am_py_exec_prefix')
-- 
2.35.1



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

2024-01-13 Thread Bogdan via Bug reports for Automake

Mike Frysinger , 2024-01-13 07:26:

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



 You're probably right. Perhaps not meant for this purpose, but I
think BUILT_SOURCES is the only way to make generated code files
visible to the build system, no matter if for dependencies or not. How
do I e.g. have a .c file generated by 'configure' to be properly built
if I can't list it in Makefile.am (because it's a .c.in file in the
beginning)?
 This was just my simple hack to help the author. There are better
solutions in this case (the ones I wrote later about), and perhaps the
author's build system/Makefile.am's/dependencies should be fixed in
the first place.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






bug#54020: Allow user-defined libtool options

2024-01-13 Thread Bogdan via Bug reports for Automake

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



 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.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






bug#54020: Allow user-defined libtool options

2024-01-14 Thread Bogdan via Bug reports for Automake

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



 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.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






bug#54020: Allow user-defined libtool options

2024-01-18 Thread Bogdan via Bug reports for Automake

Mike Frysinger , 2024-01-17 06:04:

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



 No problem. I hope I didn't sound rude or something, because that
wasn't the purpose. My mail was (supposed to be) completely neutral. I
don't get angry or something if someone reviews my patch, or modifies
it, or even completely rejects it.
 I don't know everything either and I my only purpose with adding 2
flags was to be just-in-case future-proof (so that we don't get a
similar report some time later, saying "can you make a flag like that,
because I need one after the invocation as well?", and not to support
something that already exists.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






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

2024-01-28 Thread Bogdan via Bug reports for Automake

Hello.

 The attached patch fixes the tests for Python 3.12 (and, hopefully
later ones), while still keeping them working for earlier versions.
 A simple fix. Could perhaps be written better (like in a single
Python script), but this is enough.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From dc9454621fa0fa7bf2a7ab65219f300da0ceff65 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 28 Jan 2024 23:06:27 +0100
Subject: [PATCH] Fix tests for Python 3.12

---
 t/ax/am-test-lib.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh
index fbbb79005..d61fd6662 100644
--- a/t/ax/am-test-lib.sh
+++ b/t/ax/am-test-lib.sh
@@ -635,6 +635,10 @@ python_has_pep3147 ()
 am_pep3147_tag=$($PYTHON -c 'import imp; print(imp.get_tag())') \
   || am_pep3147_tag=none
   fi
+  if test "$am_pep3147_tag" = "none"; then
+am_pep3147_tag=$($PYTHON -c 'import sys; print(sys.implementation.cache_tag)') \
+  || am_pep3147_tag=none
+  fi
   test $am_pep3147_tag != none
 }
 am_pep3147_tag=
-- 
2.35.1



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

2024-02-06 Thread Bogdan via Bug reports for Automake

Hi.

 I have access to just Linux and SunOS and cannot reproduce the error
(the tests pass), but Karl's solution seems reasonable and shouldn't hurt.
 Attaching a simple patch which (hopefully) fixes the issue. At
least, it doesn't hurt Linux or SunOS, so it shouldn't make things
worse. Feel free to reformat if needed (indents, empty lines, etc.).


--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From a96917db0534c9725d6f91b7fd5fde0abcf26ef1 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 6 Feb 2024 21:55:23 +0100
Subject: [PATCH] Fix yacc tests on OpenIndiana

---
 t/yacc-clean-cxx.sh |  8 
 t/yacc-cxx.sh   |  7 +++
 t/yacc-d-cxx.sh |  6 ++
 t/yacc-mix-c-cxx.sh | 12 
 4 files changed, 33 insertions(+)

diff --git a/t/yacc-clean-cxx.sh b/t/yacc-clean-cxx.sh
index facd6dbc4..6af2047c0 100644
--- a/t/yacc-clean-cxx.sh
+++ b/t/yacc-clean-cxx.sh
@@ -70,9 +70,17 @@ cat > sub1/parsefoo.yxx << 'END'
 %{
 // This file should contain valid C++ but invalid C.
 #include 
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
+
 // "std::" qualification required by Sun C++ 5.9.
 int yylex (void) { return std::getchar (); }
 void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
+
 %}
 %%
 x : 'x' { };
diff --git a/t/yacc-cxx.sh b/t/yacc-cxx.sh
index f6b477c0d..3f891dac5 100644
--- a/t/yacc-cxx.sh
+++ b/t/yacc-cxx.sh
@@ -54,9 +54,16 @@ cat > parse1.yy << 'END'
 using std::exit;
 using std::free;
 using std::malloc;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
 // "std::" qualification required by Sun C++ 5.9.
 int yylex (void) { return std::getchar (); }
 void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
+
 %}
 %%
 a : 'a' { exit(0); };
diff --git a/t/yacc-d-cxx.sh b/t/yacc-d-cxx.sh
index 255e00a71..556977c22 100644
--- a/t/yacc-d-cxx.sh
+++ b/t/yacc-d-cxx.sh
@@ -35,8 +35,14 @@ write_parse ()
 using std::free;
 using std::malloc;
 #include "$header"
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
 int yylex (void) { return 0; }
 void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
 %}
 %%
 x : 'x' {};
diff --git a/t/yacc-mix-c-cxx.sh b/t/yacc-mix-c-cxx.sh
index 0e7e2e104..d454fe244 100644
--- a/t/yacc-mix-c-cxx.sh
+++ b/t/yacc-mix-c-cxx.sh
@@ -54,8 +54,14 @@ END
 
 cat > p.y <<'END'
 %{
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
 int yylex (void) { int new = 0; return new; }
 void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
 %}
 %token ZARDOZ
 %%
@@ -93,8 +99,14 @@ using std::exit;
 using std::free;
 using std::malloc;
 #include "parse.hh"
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
 int yylex (void) { return 0; }
 void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
 %}
 %token FOOBAR
 %%
-- 
2.35.1



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

2024-02-13 Thread Bogdan via Bug reports for Automake

Hello, Bruno.

Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
diff --git a/t/yacc-cxx.sh b/t/yacc-cxx.sh
index 3f891dac5..effb6e282 100644
--- a/t/yacc-cxx.sh
+++ b/t/yacc-cxx.sh
@@ -51,9 +51,15 @@ cat > parse1.yy << 'END'
 // Valid C++, but deliberately invalid C.
 #include 
 #include 
+#ifdef __sun
 using std::exit;
 using std::free;
 using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
 #if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
 extern "C" {
 #endif
diff --git a/t/yacc-d-cxx.sh b/t/yacc-d-cxx.sh
index 556977c22..3885b68bb 100644
--- a/t/yacc-d-cxx.sh
+++ b/t/yacc-d-cxx.sh
@@ -31,9 +31,15 @@ write_parse ()
 #include 
 // Valid C++, but deliberately invalid C.
 #include 
+#ifdef __sun
 using std::exit;
 using std::free;
 using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
 #include "$header"
 #if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
 extern "C" {
diff --git a/t/yacc-mix-c-cxx.sh b/t/yacc-mix-c-cxx.sh
index d454fe244..dfe5feeb3 100644
--- a/t/yacc-mix-c-cxx.sh
+++ b/t/yacc-mix-c-cxx.sh
@@ -95,9 +95,15 @@ cat > parse.yy <<'END'
 #include 
 // Valid C++, but deliberately invalid C.
 #include 
+#ifdef __sun
 using std::exit;
 using std::free;
 using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
 #include "parse.hh"
 #if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
 extern "C" {


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

2024-02-18 Thread Bogdan via Bug reports for Automake

Hello, Bruno.

Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?



 Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?
 On my system, Autoconf finds "g++", tests it for an Objective C++
compiler, fails, and the t/objcxx-* tests are simply skipped.
 It seems that on your system, "c++" actually works as an Objective
C++ compiler, but somehow the "libobjc" library is not added to the
command line, making the test fail during linking.
 What Autoconf version do your have and can you upgrade that? I
suspect it's not passing the required libraries. If it's the newest
version, can you attach the config.log file?

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






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

2024-02-19 Thread Bogdan via Bug reports for Automake

Bruno Haible , 2024-02-19 01:33:

Hello Bogdan,

Thank you for dealing with the Automake support.



 Thank you for testing :)



2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?


I did not have the STRIPPROG environment variable set.



 Right. Going through the logs, through various variables, up a few
levels, this finally leads to the line

./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'

 in the test itself, and the test's description:

# Ensure install-strip works when STRIP consists of more than one word.
# This test needs GNU binutils strip.  See sister test 'strip3.sh'.


 And, frankly, I don't know what to do about this. It's the whole
point of the test to use 'strip --verbose' (well, 'strip' + any word,
actually). Fortunately, doesn't look like a bug in Automake itself.

 Perhaps we can test with some other option. Is there some useful
command-line option that your 'strip' accepts, while still performing
its work? Like neither --help nor --version?
 Come to think of it, we're not testing if the files actually got
installed, so maybe --help or --version would do after all. If you
change the above line to

./configure --prefix="$(pwd)/inst" STRIP='strip --help'

 does the test pass? (You can choose --version as well, I guess.). If
not, any other option you may suggest? We could then re-write the test
a bit to say if 'strip --verbose' works, use that. If not, try --help.



3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?


With the patch, the test succeeds.



 Good to hear.



Note, however, that 'defined __sun' is not an appropriate test for
Sun C++ (since g++ also exists on Solaris). For compiler predefined
macros, see here:
https://github.com/cpredef/predef/blob/master/Compilers.md



 The question is if we want to detect the compiler or the operating
system. I'm toying around with a SunOS with GCC installed, I'm using
__sun and some of the tests that previously failed, now work. At least
with GCC. But thanks for the reference anyway - if we need something
specific to the Sun compiler, we'll know where to look.


--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






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

2024-02-19 Thread Bogdan via Bug reports for Automake

Bruno Haible , 2024-02-19 01:44:

Hello Bogdan,


   Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?


$ c++ --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin


   On my system, Autoconf finds "g++", tests it for an Objective C++
compiler, fails, and the t/objcxx-* tests are simply skipped.
   It seems that on your system, "c++" actually works as an Objective
C++ compiler, but somehow the "libobjc" library is not added to the
command line, making the test fail during linking.


Yes, 'c++' works as an Objective-C++ compiler:



 How interesting. Especially that it compiles, but doesn't link.

[...]


$ c++ -c hello.mm
$ c++ hello.mm
[3 link errors, due to undefined symbols.]


   What Autoconf version do your have and can you upgrade that?


I was testing automake-1.16j.



 Good (even though it's 1.16.90 now :) ). Even though this looks like
a typo, I really was asking for Autoconf, suspecting a faulty test
there. But no problem, I see in config.log that it's the
latest-and-greatest 2.72.



I suspect it's not passing the required libraries. If it's the newest
version, can you attach the config.log file?


Find attached the config.log.



 Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
 Does it work if you put

AC_LANG([Objective C])

 somewhere between the lines

cat >> configure.ac << 'END'

and the first

END

following it (i.e., in the 'configure.ac' file) in the test?

 If not, do you know any function name that we could use in
AC_CHECK_LIB to check for libobjc?
 Fortunately, this looks like just an issue with tests (or Autoconf),
not Automake.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






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

2024-02-22 Thread Bogdan via Bug reports for Automake

Bruno Haible , 2024-02-20 12:44:

Bogdan wrote:

   Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
   Does it work if you put

AC_LANG([Objective C])

   somewhere between the lines

cat >> configure.ac << 'END'

and the first

END

following it (i.e., in the 'configure.ac' file) in the test?


No: With this added configure.ac line (before AC_OUTPUT), the
two tests t/objcxx-minidemo.sh and t/objcxx-deps.sh still fail.


   If not, do you know any function name that we could use in
AC_CHECK_LIB to check for libobjc?



[...]



==
produces link errors w.r.t. the symbols
   objc_autoreleasePoolPush
   objc_autoreleasePoolPop
   __objc_exec_class
Is one of them suitable for testing? It depends on the ABI. Looking at
https://opensource.apple.com/source/objc4/objc4-706/runtime/objc-abi.h.auto.html
it seems better to choose one of the symbols
   _objcInit
   objc_getProperty
   objc_setProperty
   objc_setProperty_atomic
   objc_setProperty_nonatomic
   ...
   objc_copyStruct
   objc_copyCppObjectAtomic
   _objc_empty_cache
   ...

But wait! The name of the library 'libobjc' is not standardized either.

I would try to just compile a simple Objective-C++ program and see whether that
works or not. Such as:



That's what I would expect from Autoconf...
[...]



===
Missing symbols with clang on OpenBSD:
   objc_msg_lookup_sender
   __objc_exec_class
Missing symbols with clang on Ubuntu:
   objc_msg_lookup
   __objc_exec_class



[...]

 Assuming that the library is named "libobjc", I'm attaching a patch
that searches for the above symbols in the library. The tests worked
for me without this, and work after. Feel free to add more rows if the
library name is different.

Gathering the other thread:

> So, in summary, I suggest to use the option '-x' instead of
'--verbose'.
> It makes the t/strip2.sh test succeed on OpenBSD. Then you can
remove the comment "This test needs GNU binutils strip.".


Patch attached.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From 06852fb43569eac608b95dea838858cd75e37327 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 22 Feb 2024 22:03:29 +0100
Subject: [PATCH] Try to fix Objective-c++ on OpenBSD

---
 t/objcxx-deps.sh | 4 
 t/objcxx-minidemo.sh | 4 
 2 files changed, 8 insertions(+)

diff --git a/t/objcxx-deps.sh b/t/objcxx-deps.sh
index 1f39507fd..519c33244 100644
--- a/t/objcxx-deps.sh
+++ b/t/objcxx-deps.sh
@@ -21,6 +21,10 @@
 
 cat >> configure.ac << 'END'
 AC_PROG_OBJCXX
+AC_CHECK_LIB([objc],[__objc_exec_class])
+AC_CHECK_LIB([objc],[objc_getProperty])
+AC_CHECK_LIB([objc],[objc_msg_lookup_sender])
+AC_CHECK_LIB([objc],[objc_msg_lookup])
 AC_OUTPUT
 END
 
diff --git a/t/objcxx-minidemo.sh b/t/objcxx-minidemo.sh
index ec0e8e129..f6f53c151 100644
--- a/t/objcxx-minidemo.sh
+++ b/t/objcxx-minidemo.sh
@@ -23,6 +23,10 @@ required=native
 cat >> configure.ac << 'END'
 AC_PROG_OBJCXX
 AC_CONFIG_HEADERS([config.h])
+AC_CHECK_LIB([objc],[__objc_exec_class])
+AC_CHECK_LIB([objc],[objc_getProperty])
+AC_CHECK_LIB([objc],[objc_msg_lookup_sender])
+AC_CHECK_LIB([objc],[objc_msg_lookup])
 AC_OUTPUT
 END
 
-- 
2.35.1

From 4005c0dee31133571c31e79fb5c248731e135f0c Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 22 Feb 2024 21:01:39 +0100
Subject: [PATCH] Fix strip on OpenBSD and others

---
 t/strip2.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/strip2.sh b/t/strip2.sh
index a367dd0fe..e48dddc7a 100644
--- a/t/strip2.sh
+++ b/t/strip2.sh
@@ -15,7 +15,7 @@
 # along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
 # Ensure install-strip works when STRIP consists of more than one word.
-# This test needs GNU binutils strip.  See sister test 'strip3.sh'.
+# See sister test 'strip3.sh'.
 
 required='cc strip'
 . test-init.sh
@@ -39,7 +39,7 @@ $ACLOCAL
 $AUTOCONF
 $AUTOMAKE -a
 
-./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'
+./configure --prefix="$(pwd)/inst" STRIP='strip -x'
 $MAKE
 $MAKE install-strip
 
-- 
2.35.1



bug#68860: race condition with make recheck

2024-08-16 Thread Bogdan via Bug reports for Automake

Hello.

Thank you for reporting the issue.

The attached patch should fix the problem. It may be a bit of an
overkill, perhaps just one of the fixes would suffice, but it seems to
work at least.

I've re-made your useful script into an Automake test. Since
non-deterministic defects may be hard to find and fix, and certainly
harder to test if they're fixed, the new version simply runs parallel
'make recheck' a few times "just in case". Without the fix, the test
failed in the first or the second run. With the fix, the test (which
runs 'make recheck' 5 times) passed 5 times in a row. This *should* be
a decent sample.

All tests with "check" in the name pass.

The test and my patch can, of course, be adapted and further changed.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From eb64fc56f13955a0b05b89492f48df886311191f Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sat, 17 Aug 2024 00:17:35 +0200
Subject: [PATCH] Bug#68860 Fix race condition in recheck

---
 bin/automake.in|   6 +-
 lib/am/check.am|   2 +-
 t/list-of-tests.mk |   1 +
 t/recheck-race.sh  | 135 +
 4 files changed, 141 insertions(+), 3 deletions(-)
 create mode 100644 t/recheck-race.sh

diff --git a/bin/automake.in b/bin/automake.in
index a17f45236..1d6c29d1c 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -4705,12 +4705,14 @@ sub do_check_merge_target ()
   # The check target must depend on the local equivalent of
   # 'all', to ensure all the primary targets are built.  Then it
   # must build the local check rules.
-  $output_rules .= "check-am: all-am\n";
+  $output_rules .= "check-am: all-am";
   if (@check)
 {
-  pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
+  $output_rules .= " @check";
+  #pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
   depend ('.MAKE', 'check-am');
 }
+  $output_rules .= "\n";
 
   if (@check_tests)
 {
diff --git a/lib/am/check.am b/lib/am/check.am
index e51a771bf..72c71a0f4 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -480,7 +480,7 @@ check-TESTS: %CHECK_DEPS%
 
 ## Recheck must depend on $(check_SCRIPTS), $(check_PROGRAMS), etc.
 ## It must also depend on the 'all' target.  See automake bug#11252.
-recheck: all %CHECK_DEPS%
+recheck: all-am %CHECK_DEPS%
 ## See comments above in the check-TESTS recipe for why remove
 ## $(TEST_SUITE_LOG) here.
 	@$(am__rm_f) $(TEST_SUITE_LOG)
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index e80ace470..f359ba8a1 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -824,6 +824,7 @@ t/parallel-tests-no-spurious-summary.sh \
 t/parallel-tests-exit-statuses.sh \
 t/parallel-tests-console-output.sh \
 t/parallel-tests-once.sh \
+t/recheck-race.sh \
 t/tests-environment.sh \
 t/am-tests-environment.sh \
 t/tests-environment-backcompat.sh \
diff --git a/t/recheck-race.sh b/t/recheck-race.sh
new file mode 100644
index 0..abeb8c441
--- /dev/null
+++ b/t/recheck-race.sh
@@ -0,0 +1,135 @@
+#! /bin/sh
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+# Test for race conditions in 'make recheck'.
+
+. test-init.sh
+
+cat > configure.ac < Makefile.am < foo.h <
+std::string foo(void);
+#endif
+EOF
+
+cat > foo.cc <
+#include "foo.h"
+std::string foo(void) { return "fu"; }
+
+EOF
+
+cat > one.cc <
+#include "foo.h"
+#include "test.h"
+#include 
+#include 
+int main(int argc, char* argv[])
+{
+	init(argc, argv);
+	std::cout << "Hello World!\n" << foo() << "\n";
+	return 0;
+}
+EOF
+
+cat > two.cc <
+#include "foo.h"
+#include "test.h"
+#include 
+#include 
+int main(int argc, char* argv[])
+{
+	init(argc, argv);
+	std::string str = foo();
+	if (str != "foo") {
+	   std::cerr << "error: foo(): " << str <

bug#69908: [PATCH] Fix for no-dist-built-sources

2024-08-22 Thread Bogdan via Bug reports for Automake

Hello.

Thank you for reporting the issue.

I believe I have fixed the defect. The attached patch assumes that
"no-dist-built-sources" is the right option name, following the
documentation and the Options.pm file.

Automake itself has been changed to process the option correctly,
distdir.am got the reversed condition fixed (!) and a new test has
been added based on the one provided in the defect report (thank you!).

All tests with "dist" in the name pass.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org
From 2eeff35bcb64c9f3c6651773344483d404c6580a Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 22 Aug 2024 23:10:38 +0200
Subject: [PATCH] Fix no-dist-built-sources

---
 bin/automake.in| 2 +-
 lib/am/distdir.am  | 4 ++--
 t/dist-no-built-sources.sh | 7 +++
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/bin/automake.in b/bin/automake.in
index a17f45236..ee196f28b 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -6903,7 +6903,7 @@ sub preprocess_file
 		 'SHAR'=> !! option 'dist-shar',
 		 'ZIP' => !! option 'dist-zip',
 		 'ZSTD'=> !! option 'dist-zstd',
-		 'DIST_BUILT_SOURCES' => !! option 'dist-built-sources',
+		 'DIST_BUILT_SOURCES' => ! option 'no-dist-built-sources',
 
 		 'INSTALL-INFO' =>  ! option 'no-installinfo',
 		 'INSTALL-MAN'  =>  ! option 'no-installman',
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index c85f6a325..810290477 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -76,10 +76,10 @@ AM_RECURSIVE_TARGETS += distdir distdir-am
 endif %?SUBDIRS%
 
 if %?DIST_BUILT_SOURCES%
-distdir:
+distdir: $(BUILT_SOURCES)
 	$(MAKE) $(AM_MAKEFLAGS) distdir-am
 else !%?DIST_BUILT_SOURCES%
-distdir: $(BUILT_SOURCES)
+distdir:
 	$(MAKE) $(AM_MAKEFLAGS) distdir-am
 endif !%?DIST_BUILT_SOURCES%
 
diff --git a/t/dist-no-built-sources.sh b/t/dist-no-built-sources.sh
index d891f3a13..f5891bab4 100644
--- a/t/dist-no-built-sources.sh
+++ b/t/dist-no-built-sources.sh
@@ -26,6 +26,11 @@ for testopt in no-built-sources dist-built-sources; do
 configure.ac >configure.tmp
 cmp configure.ac configure.tmp && fatal_ 'failed to edit configure.ac'
 mv -f configure.tmp configure.ac
+  else
+sed -e 's/AM_INIT_AUTOMAKE(\[no-dist-built-sources\])/AM_INIT_AUTOMAKE/' \
+configure.ac >configure.tmp
+cmp configure.ac configure.tmp && fatal_ 'failed to edit configure.ac'
+mv -f configure.tmp configure.ac
   fi
 
   cat >> configure.ac << 'END'
@@ -66,9 +71,11 @@ EOF
   if test "$testopt" = no-built-sources; then
 # no-built-sources should not have generated this
 ! test -e x.c
+$EGREP "distdir:$" Makefile
   else
 # built-sources build should have it
 test -e x.c
+grep "distdir: \$(BUILT_SOURCES)" Makefile
   fi
 
   # If the test runs fast enough, the make dist second time through
-- 
2.35.1



bug#68860: race condition with make recheck

2024-08-23 Thread Bogdan via Bug reports for Automake

Hi.

I've just noticed that bug #68860 (patched) may be a duplicate of
#26471. Different descriptions and error messages, but looks like the
same cause.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org






bug#68860: race condition with make recheck

2024-08-25 Thread Bogdan via Bug reports for Automake

Karl Berry , 2024-08-25 10:45:

Thanks much, Bogdan.

 -recheck: all %CHECK_DEPS%
 +recheck: all-am %CHECK_DEPS%

Do you have a grip on all-am? Looking at handle_all in bin/automake, I
admit I remain baffled as to what all those pieces of all-am are, and
why it's done as it is.



 Te be honest, not really :). At least, not fully. As far as I
understand/remember, those "all-am" were the ones processed
recursively. But, I may be wrong, seeing this comment in handle_all:

# We need to make sure config.h is built before we recurse.
# We also want to make sure that built sources are built
# before any ordinary 'all' targets are run.  We can't do this
# by changing the order of dependencies to the "all" because
# that breaks when using parallel makes.  Instead we handle
# things explicitly.

So, "all" just checks/remakes config.h before starting "the real work"
in all-am (be it recursive or not, parallel or not).



 -  $output_rules .= "check-am: all-am\n";
 +  $output_rules .= "check-am: all-am";
if (@check)
  {
 -  pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
 +  $output_rules .= " @check";
 +  #pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", @check);
depend ('.MAKE', 'check-am');
  }
 +  $output_rules .= "\n";

So I gather the basic fix to output the check targets as dependencies of
check-am, instead of as sub-makes. That seems a plausible reason and fix
for the parallel bug to me.



 Yes, I'm adding the dependencies as I believe they should be. Here
and in check.am. Maybe the check.am is too much (especially seeing
that skipping the dependency on config.h may *not* be desired) and
fixing only the code will be enough.
 As it is with non-deterministic problem, it's not 100% guaranteed
that this fixes the problem. But, a few runs of parallel 'make
recheck' seems to prove it.



Anyway, I will tweak a few words and install this soon. --thanks again, karl.



 No problem. And thanks :)

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org





bug#68860: race condition with make recheck

2024-08-26 Thread Bogdan via Bug reports for Automake

Karl Berry , 2024-08-25 19:17:

 >  -  $output_rules .= "check-am: all-am\n";
 >  +  $output_rules .= "check-am: all-am";
 > if (@check)
 >   {
 >  -  pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t  ", 
@check);
 >  +  $output_rules .= " @check";

Looking again, the comment before this code says:

   # The check target must depend on the local equivalent of
   # 'all', to ensure all the primary targets are built.  Then it
   # must build the local check rules.

.. which makes sense. We have to make all before we can make check.
Hence the check targets can't be dependencies, since then they would be
run in parallel with make, and the programs built by 'all' might not be
built yet. This explains why they made it a sub-make.



 Totally makes sense, and I'm not removing the dependency on all-am.
When I see that the first command of a target is a 'make', I start
thinking that something in dependency management is wrong. It
shouldn't be needed, right? That's one of the jobs 'make' does -
figure out what needs to be built and in what order. So, if the
dependencies would be correct in the first place, maybe running 'make'
in a target wouldn't be needed (well, not in the beginning, at least).
That's why I'm adding @check to the dependency list instead of
building it manually as the first command. The dependencies /should/
be computed correctly and built just once (if needed, that is).

 But, correct dependencies are maybe just in the perfect world.

 There probably were reasons to do it this way, like parallel make
(which /should/ work correctly, but maybe not all implementations do)
or some implementations that e.g. don't follow the order and break the
builds because of that, or too many too complicated dependencies to
put on each target, or...

 So, what do we do? It has just become a bit scary to apply the
patch, but it looks like it's exactly the dependency list that should
be fixed...



So I'm puzzled as to how all the tests can still be passing. Maybe there
is no test specifically for this? --thanks, karl.



 Maybe. Or maybe tests pass on the well-behaving GNU Make, but not on
all 'make's. Or I didn't run the "right ones".


--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org





bug#73316: Numeric user ID too large when generating the tarball

2024-09-17 Thread glorenzetti--- via Bug reports for Automake

Good morning,

GNU Astronomy Utilities (Gnuastro) uses GNU Autotools. A Gnuastro 
developer encountered the "Numeric user ID too large" error when 
generating a tarball with the 'make dist' command on his macOS (Monterey 
12.3) laptop. His user id is an integer with 9 digits, which is too big 
for the old v7 and ustar formats of tar.


The issue is discussed in Gnuastro's bug tracker 
(https://savannah.gnu.org/bugs/?65578), where the work-around conclusion 
was to use a conditional that adds 'tar-pax' to 'AM_INIT_AUTOMAKE' when 
the user ID is so large. For reference, here is Gnuastro's configure.ac: 
https://git.savannah.gnu.org/cgit/gnuastro.git/tree/configure.ac#n44
The issue was also erroneusly reported in autoconf's bug tracker 
(https://savannah.gnu.org/support/?23).


Even though we encountered this problem in macOS, this problem may not 
be limited to it. Other user management systems who use such large IDs 
may also cause this issue.


While it is possible to write such workaround downstream in Gnuastro, it 
would be nice to have the issue solved upstream in the GNU Autotools 
since it can happen for any other developer of other software that uses 
Autotools.


Best Regards,
Giacomo Lorenzetti





bug#73316: Numeric user ID too large when generating the tarball

2024-09-19 Thread glorenzetti--- via Bug reports for Automake

Hi Karl,

thanks for the detailed answers.
We've run few more tests, and we've found a couple more issues.

1. As you pointed out, TAR_OPTIONS is working fine from the command 
line, but it doesn't work when written inside Makefile.am, neither on 
Mac, nor on Linux.

$ TAR_OPTIONS="--version"
$ export TAR_OPTIONS

2. The workaround we were attempting uses an AS_IF to initialize a 
variable to be used as argument in AM_INIT_AUTOMAKE, but 
AM_INIT_AUTOMAKE is reading that variable as an option. Are we missing 
something regarding the syntax of autotools?


3. Feature request: it would be nice to have a "tar-no-owner" option for 
AM_INIT_AUTOMAKE that sets user and group ids to 0. (The "privileges" 
issue apparently is only when extracting with --same-owner, so intended)


Best,
Giacomo





bug#42393: Testsuite summary for GNU Automake 1.16.1 : FAIL: 6

2020-07-16 Thread Dennis Clarke via Bug reports for Automake


These look to be minor but on an old Solaris 10 server they do indeed
 exist :

FAIL: t/lex-clean-cxx.sh
FAIL: t/lex-depend-cxx.sh
FAIL: t/silent-many-languages.sh
FAIL: t/yacc-cxx.sh
FAIL: t/yacc-d-cxx.sh
FAIL: t/yacc-mix-c-cxx.sh

This is an Oracle/Fujitsu M-class SPARC-VII+ server under support
contract and kept fairly well up to date. The compiler tools were
the Oracle Studio 12.6 ( was Sun Studio which was Forte ) tools.

I will attach a tarball of the logs files for these tests as well
as the environment variable state and the result from configure run
which was trivial :

./configure --prefix=/opt/bw --disable-silent-rules

Most of the GNU toolchain that has been built thus far is very very
up to date and had no problems :

alpha$
alpha$ /opt/bw/bin/m4 --version
m4 (GNU M4) 1.4.18
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Rene' Seindal.
alpha$ /opt/bw/bin/bison --version
bison (GNU Bison) 3.6.91
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
alpha$ /opt/bw/bin/autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>,
<http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
alpha$ /opt/bw/bin/bash --version
GNU bash, version 5.0.18(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
alpha$ /opt/bw/bin/gettext --version
gettext (GNU gettext-runtime) 0.20.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Ulrich Drepper.
alpha$ /opt/bw/bin/idn --version
idn (GNU Libidn) 1.35
Copyright (C) 2018 Simon Josefsson.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Simon Josefsson.
alpha$ /opt/bw/bin/idn2 --version
idn2 (libidn2) 2.3.0
Copyright 2011-(C) 2019 Simon Josefsson, Tim Ruehsen.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Simon Josefsson, Tim Ruehsen.
alpha$ /opt/bw/bin/patch --version
GNU patch 2.7.6
Copyright (C) 2003, 2009-2012 Free Software Foundation, Inc.
Copyright (C) 1988 Larry Wall

License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Larry Wall and Paul Eggert
alpha$ /opt/bw/bin/perl -V 2>&1 | head -20
Summary of my perl5 (revision 5 version 32 subversion 0) configuration:

  Platform:
osname=solaris
osvers=2.10
archname=sun4-solaris-64-ld
uname='sunos alpha 5.10 generic_150400-65 sun4u sparc
sunw,sparc-enterprise '
config_args='-Dprefix=/opt/bw -Dmksymlinks -Accflags=-m64
-xarch=sparc -g -Xa -errfmt=error -erroff=%none -errshort=full
-xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl
-xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -L/opt/bw/lib
-I/opt/bw/include'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=define
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
  Compiler:
alpha$

Just curious about these automake errors.

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional


automake-1.16.1_sunos5.10_sparcv9_test_logs.tar.xz
Description: application/xz


bug#42665: New tests failures with autoconf-2.69b (beta)

2020-08-01 Thread Ken Moffat via Bug reports for Automake
I tested automake-1.16.2 in a fresh build on top of autoconf-2.69b
(latest beta).  Instead of all automakes tests passing or skipping,
as happened with autoconf-2.69, I now have 2 new failures (but
autoconf now has zero failures, which is a big improvement).

Already reported to autoconf (with typo in subject), but copying you
on the new errors in case you care.

ĸen

===
   GNU Automake 1.16.2: ./test-suite.log
===

# TOTAL: 2915
# PASS:  2718
# SKIP:  156
# XFAIL: 39
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

[ cutting down to only the failures ]

FAIL: t/autohdr4


Running from installcheck: no
Test Protocol: none
PATH = 
/building/automake-1.16.2/bin:/building/automake-1.16.2/t/ax:/bin:/usr/bin:/sbin:/usr/sbin
++ pwd
/building/automake-1.16.2/t/autohdr4.dir
+ cat
+ mkdir sub1 sub2 sub3
+ :
+ echo '#define NAME "grepme1"'
+ cat
+ cat
+ cat
+ aclocal-1.16 -Werror
+ autoconf
+ autoheader
autoheader: cannot open sub2/config.${BOT}: No such file or directory
+ am_exit_trap 1
+ exit_status=1
+ set +e
+ cd /building/automake-1.16.2
+ test none = tap
+ case $am_explicit_skips in
+ test 1 -eq 0
+ keep_testdirs=yes
+ am_keeping_testdirs
+ case $keep_testdirs in
+ return 0
+ set +x
FAIL t/autohdr4.sh (exit status: 1)

FAIL: t/autohdr-subdir-pr12495
==

Running from installcheck: no
Test Protocol: none
PATH = 
/building/automake-1.16.2/bin:/building/automake-1.16.2/t/ax:/bin:/usr/bin:/sbin:/usr/sbin
++ pwd
/building/automake-1.16.2/t/autohdr-subdir-pr12495.dir
+ cat
+ mkdir sub
+ echo SUBDIRS = sub
+ :
+ aclocal-1.16 -Werror
+ autoconf
+ autoheader
autoheader: cannot open b.h.in: No such file or directory
+ am_exit_trap 1
+ exit_status=1
+ set +e
+ cd /building/automake-1.16.2
+ test none = tap
+ case $am_explicit_skips in
+ test 1 -eq 0
+ keep_testdirs=yes
+ am_keeping_testdirs
+ case $keep_testdirs in
+ return 0
+ set +x
FAIL t/autohdr-subdir-pr12495.sh (exit status: 1)

-- 
Juliet's version of cleanliness was next to godliness, which was to
say it was erratic, past all understanding and was seldom seen.
  -- Unseen Academicals





bug#44010: Per-compilation C files

2020-10-15 Thread Reuben Thomas via Bug reports for Automake
I've recently started using automake with Vala; it works very well! I'm
particularly impressed that the "make dist" rules include the C files, so
that the builder doesn't need a Vala compiler.

There's one nit: I want to make multiple .c files from the same .vala file,
analogous to the way that you can make multiple .o files from the same .c
file, and it doesn't seem to work: automake generates two sets of rules for
the same .c file instead.

The use case is a Vala file directly translated from a C file, which
contains a test bracketed with #if TEST … #endif.

In the C version of the project I have:

TESTS = estr
estr_CPPFLAGS = …
estr_LDADD = …

as well as

zile_SOURCES = … estr.c …

for the main program, and for the test program, automake generates a rule
for estr-estr.$(OBJEXT).

In the Vala version, I have

TESTS = estr
estr_SOURCES = estr.vala # so that automake doesn't try to just compile
estr.c
estr_VALAFLAGS = …
estr_CPPFLAGS = …
estr_LDFLAGS = …

as well as

zile_SOURCE = … estr.vala …

A quick look at `automake.in` suggests that the problem is that this
intelligence applies specifically to object files, rather than to arbitrary
compilation steps?

-- 
https://rrt.sc3d.org


bug#44011: Improvements to contrib/README

2020-10-15 Thread Reuben Thomas via Bug reports for Automake
I attach a patch relative to current git that improves contrib/README.

-- 
https://rrt.sc3d.org
From 759746989cc75c2a929c09b28226d9be18d64a21 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Thu, 15 Oct 2020 13:11:11 +0100
Subject: [PATCH] contrib/README: fix and clarify the English

---
 contrib/README | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/contrib/README b/contrib/README
index a4d7eeb8d..f43e1da9b 100644
--- a/contrib/README
+++ b/contrib/README
@@ -1,26 +1,23 @@
 This is the 'contrib' directory of the GNU Automake distribution.
 
-Here you'll find additions to the Automake base distribution, in form of
-makefile fragments, m4 macros, scripts, documentation, et cetera.  Such
-addition that might be useful for a significant percentage of its general
-audience, but (for one reason or another) are not deemed appropriate for
-inclusion into the Automake core.
+Here you'll find additions to the Automake base distribution, in the form of
+makefile fragments, m4 macros, scripts, documentation, et cetera: additions
+that might be handy to many users, but (for one reason or another) are not
+deemed appropriate for inclusion into the Automake core.
 
-There are several reasons for which a feature can be kept in contrib:
+There are several reasons that a feature might be kept in contrib:
 
   1. The long-term usefulness of the feature is debatable and uncertain;
- on-field and real-word testing are necessary to prove or disprove
- its usefulness, before the feature can be committed into the Automake
- core (as doing so too early would later force us to continue the
- support for backward-compatibility, even if the features proves
- flawed or fails to attract widespread use).
+ real-world testing is necessary to prove or disprove its usefulness,
+ before the feature can be committed into the Automake core (as doing so
+ too early would later force us to continue support for
+ backward-compatibility, even if the feature proved flawed or fails to
+ attract widespread use).
 
-  2. The APIs or overall design of the feature are still unstable, and
- need on-field testing to iron warts and usability bugs, or uncover
- potential flaws.
+  2. The APIs or overall design of the feature are still unstable, and need
+ testing to iron out warts and usability bugs, or uncover potential flaws.
 
-  3. The feature was an historical one, mostly obsoleted but still used
- "here and there" in the wild; so we want to to deprecate it and
-     remove it from the Automake core, but cannot remove it altogether,
- for the sake of those still-existing usage.  So it gets moved in
- contrib.
+  3. The feature was an historical one, mostly obsolete but still used in the
+ wild.  We want to deprecate it and remove it from the Automake core, but
+ cannot remove it altogether, for the sake of the existing usage, so it
+ gets moved in contrib.
-- 
2.25.1



bug#44010: Per-compilation C files

2020-10-15 Thread Reuben Thomas via Bug reports for Automake
On Thu, 15 Oct 2020 at 13:06, Reuben Thomas  wrote:

> I've recently started using automake with Vala; it works very well! I'm
> particularly impressed that the "make dist" rules include the C files, so
> that the builder doesn't need a Vala compiler.
>
> There's one nit: I want to make multiple .c files from the same .vala
> file, analogous to the way that you can make multiple .o files from the
> same .c file, and it doesn't seem to work: automake generates two sets of
> rules for the same .c file instead.
>

I just noticed that in fact there seems to be a bug (or at least something
I don't understand how to use!) in the Vala rules. In my case that I
mentioned before:

TESTS = estr
> estr_SOURCES = estr.vala # so that automake doesn't try to just compile
> estr.c
> estr_VALAFLAGS = …
> estr_CPPFLAGS = …
> estr_LDFLAGS = …
>
> as well as
>
> zile_SOURCE = … estr.vala …
>

estr.vala is used twice. This causes two Makefile rules for estr.c to be
generated, which conflict. Importantly, they satisfy different stamp files,
so they could cause the file not to be rebuilt for one target.

I guess I could work around this by building estr.vala into a library that
is used by both its targets, but that seems a little convoluted; is there
something I'm missing?

-- 
https://rrt.sc3d.org


bug#44010: Per-compilation C files

2020-10-15 Thread Reuben Thomas via Bug reports for Automake
I'm sorry, I see this question is covered in the manual:

Note that currently, you cannot use per-target ‘*_VALAFLAGS’ (*note
> Renamed Objects::) to produce different C files from one Vala source
> file.
>

Feel free to close this issue!


bug#44010: Per-compilation C files

2020-10-15 Thread Reuben Thomas via Bug reports for Automake
On Thu, 15 Oct 2020 at 22:09, Karl Berry  wrote:

>
> I found some long-ago patches (not for this particular issue) from a
> previous contributor (Daniel Espinosa), which surely worked at the time
> they were written, but now break things. And Daniel stopped replying to
> my mail. Sorry to be so vague, but memory is failing. If you want to
> take a look, I can dig them up.
>

Karl, thanks very much for getting back to me! In the last two weeks as
I've worked on Vala, I've already taken over Emacs's vala-mode, and I'm in
the middle of trying to add ctags support to universal ctags, based on
someone else's abandoned effort, so I'd be happy to have a look at Daniel's
patches and see if I can salvage anything useful!

-- 
https://rrt.sc3d.org


bug#44129: Patch to improve valac version detection

2020-10-21 Thread Reuben Thomas via Bug reports for Automake
Attached, a patch to improve valac version detection. The vala compiler,
valac, can report the API version it supports. For releases, this is the
same as the major & minor version of the compiler, so for example:

$ valac --version
Vala 0.48.11
$ valac --api-version
0.48

The advantage of using the API version is that it's semantically
meaningful. It's also simpler to parse! It can be to allow a 3rd-party,
patched, or unreleased compiler to be used more easily.

(For example, the current Vala git master compiler reports:

$ valac-0.52 --version
Vala 0.50.1.19-135c0
$ valac-0.52 --api-version
0.52

)

-- 
https://rrt.sc3d.org
From 3cb4252dd8e182bab5f484d3a8dd7a96f6da2180 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 21 Oct 2020 23:31:46 +0100
Subject: [PATCH] Improve Vala compiler detection: use API version, not
 compiler version

* m4/vala.m4: check `valac --api-version', not `valac --version'.
* doc/automake.texi: update documentation.
---
 doc/automake.texi | 15 +--
 m4/vala.m4| 28 +++-
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index 91e1d679a..dbeaf01f5 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6969,12 +6969,15 @@ number.
 Search for a Vala compiler in @env{PATH}.  If it is found, the variable
 @code{VALAC} is set to point to it (see below for more details).  This
 macro takes three optional arguments.  The first argument, if present,
-is the minimum version of the Vala compiler required to compile this
-package.  If a compiler is found and satisfies @var{minimum-version},
-then @var{action-if-found} is run (this defaults to do nothing).
-Otherwise, @var{action-if-not-found} is run.  If @var{action-if-not-found}
-is not specified, the default value is to print a warning in case no
-compiler is found, or if a too-old version of the compiler is found.
+is the minimum version of the Vala API required to compile this package.
+For Vala releases, this is the same as the major and minor release
+number; e.g., when @code{valac --version} reports @code{0.48.7},
+@code{valac --api-version} reports @code{0.48}.  If a compiler is found
+and satisfies @var{minimum-version}, then @var{action-if-found} is run
+(this defaults to do nothing).  Otherwise, @var{action-if-not-found} is
+run.  If @var{action-if-not-found} is not specified, the default value
+is to print a warning in case no compiler is found, or if a too-old
+version of the compiler is found.
 @end defmac
 
 There are a few variables that are used when compiling Vala sources:
diff --git a/m4/vala.m4 b/m4/vala.m4
index 759061dc0..509904b11 100644
--- a/m4/vala.m4
+++ b/m4/vala.m4
@@ -6,23 +6,25 @@
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
-# Check whether the Vala compiler exists in $PATH.  If it is found, the
-# variable VALAC is set pointing to its absolute path.  Otherwise, it is
-# simply set to 'valac'.
-# Optionally a minimum release number of the compiler can be requested.
-# If the ACTION-IF-FOUND parameter is given, it will be run if a proper
-# Vala compiler is found.
-# Similarly, if the ACTION-IF-FOUND is given, it will be run if no proper
-# Vala compiler is found.  It defaults to simply print a warning about the
-# situation, but otherwise proceeding with the configuration.
+# Search for a Vala compiler in PATH.  If it is found, the variable VALAC is
+# set to point to it.  Otherwise, it is simply set to 'valac'.  This macro
+# takes three optional arguments.  The first argument, if present, is the
+# minimum version of the Vala API required to compile this package.  For Vala
+# releases, this is the same as the major and minor release number; e.g., when
+# `valac --version' reports 0.48.7, `valac --api-version' reports 0.48.  If a
+# compiler is found and satisfies MINIMUM-VERSION, then ACTION-IF-FOUND is run
+# (this defaults to do nothing).  Otherwise, ACTION-IF-NOT-FOUND is run.  If
+# ACTION-IF-NOT-FOUND is not specified, the default value is to print a
+# warning in case no compiler is found, or if a too-old version of the
+# compiler is found.
 #
 # AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
 # --
 AC_DEFUN([AM_PROG_VALAC],
   [AC_PATH_PROG([VALAC], [valac], [valac])
AS_IF([test "$VALAC" != valac && test -n "$1"],
-  [AC_MSG_CHECKING([whether $VALAC is at least version $1])
-   am__vala_version=`$VALAC --version | sed 's/Vala  *//'`
+  [AC_MSG_CHECKING([whether $VALAC supports at least API version $1])
+   am__vala_version=`$VALAC --api-version`
AS_VERSION_COMPARE([$1], ["$am__vala_version"],
  [AC_MSG_RESULT([yes])],
  [AC_MSG_RESULT([yes])],
@@ -30,8 +32,8 @@ AC_DEFUN([AM_PROG_VALAC],
   VALAC=valac])])
 if test "$VALAC" = valac; then
   m4_default([$3]

bug#44129: Patch to improve valac version detection

2020-10-23 Thread Reuben Thomas via Bug reports for Automake
Sorry, I simply failed to update the test; I noticed a failure message, and
didn't understand it. Simply lack of effort on my part, apologies.

I attach an updated patch, which now also patches the test to account for
the new mode of operation (checking --api-version not --version) and
updated error message in case of failure.
From 0b6fecf316b7293b7ea66fbcdeb9f713dcdab4e1 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 21 Oct 2020 23:31:46 +0100
Subject: [PATCH] Improve Vala compiler detection: use API version, not
 compiler version

* m4/vala.m4: check `valac --api-version', not `valac --version'.
* doc/automake.texi: update documentation.
---
 doc/automake.texi   | 15 +--
 m4/vala.m4  | 28 +++-
 t/vala-configure.sh | 10 --
 3 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index 91e1d679a..dbeaf01f5 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6969,12 +6969,15 @@ number.
 Search for a Vala compiler in @env{PATH}.  If it is found, the variable
 @code{VALAC} is set to point to it (see below for more details).  This
 macro takes three optional arguments.  The first argument, if present,
-is the minimum version of the Vala compiler required to compile this
-package.  If a compiler is found and satisfies @var{minimum-version},
-then @var{action-if-found} is run (this defaults to do nothing).
-Otherwise, @var{action-if-not-found} is run.  If @var{action-if-not-found}
-is not specified, the default value is to print a warning in case no
-compiler is found, or if a too-old version of the compiler is found.
+is the minimum version of the Vala API required to compile this package.
+For Vala releases, this is the same as the major and minor release
+number; e.g., when @code{valac --version} reports @code{0.48.7},
+@code{valac --api-version} reports @code{0.48}.  If a compiler is found
+and satisfies @var{minimum-version}, then @var{action-if-found} is run
+(this defaults to do nothing).  Otherwise, @var{action-if-not-found} is
+run.  If @var{action-if-not-found} is not specified, the default value
+is to print a warning in case no compiler is found, or if a too-old
+version of the compiler is found.
 @end defmac
 
 There are a few variables that are used when compiling Vala sources:
diff --git a/m4/vala.m4 b/m4/vala.m4
index 759061dc0..509904b11 100644
--- a/m4/vala.m4
+++ b/m4/vala.m4
@@ -6,23 +6,25 @@
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
 
-# Check whether the Vala compiler exists in $PATH.  If it is found, the
-# variable VALAC is set pointing to its absolute path.  Otherwise, it is
-# simply set to 'valac'.
-# Optionally a minimum release number of the compiler can be requested.
-# If the ACTION-IF-FOUND parameter is given, it will be run if a proper
-# Vala compiler is found.
-# Similarly, if the ACTION-IF-FOUND is given, it will be run if no proper
-# Vala compiler is found.  It defaults to simply print a warning about the
-# situation, but otherwise proceeding with the configuration.
+# Search for a Vala compiler in PATH.  If it is found, the variable VALAC is
+# set to point to it.  Otherwise, it is simply set to 'valac'.  This macro
+# takes three optional arguments.  The first argument, if present, is the
+# minimum version of the Vala API required to compile this package.  For Vala
+# releases, this is the same as the major and minor release number; e.g., when
+# `valac --version' reports 0.48.7, `valac --api-version' reports 0.48.  If a
+# compiler is found and satisfies MINIMUM-VERSION, then ACTION-IF-FOUND is run
+# (this defaults to do nothing).  Otherwise, ACTION-IF-NOT-FOUND is run.  If
+# ACTION-IF-NOT-FOUND is not specified, the default value is to print a
+# warning in case no compiler is found, or if a too-old version of the
+# compiler is found.
 #
 # AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
 # --
 AC_DEFUN([AM_PROG_VALAC],
   [AC_PATH_PROG([VALAC], [valac], [valac])
AS_IF([test "$VALAC" != valac && test -n "$1"],
-  [AC_MSG_CHECKING([whether $VALAC is at least version $1])
-   am__vala_version=`$VALAC --version | sed 's/Vala  *//'`
+  [AC_MSG_CHECKING([whether $VALAC supports at least API version $1])
+   am__vala_version=`$VALAC --api-version`
AS_VERSION_COMPARE([$1], ["$am__vala_version"],
  [AC_MSG_RESULT([yes])],
  [AC_MSG_RESULT([yes])],
@@ -30,8 +32,8 @@ AC_DEFUN([AM_PROG_VALAC],
   VALAC=valac])])
 if test "$VALAC" = valac; then
   m4_default([$3],
-[AC_MSG_WARN([no proper vala compiler found])
- AC_MSG_WARN([you will not be able to compile vala source files])])
+[AC_MSG_WARN([Vala compiler not found or too old])
+ AC_MSG_WARN([you will not be able to compile Vala source fi

bug#13002: Dealing with C intermediate files

2020-10-23 Thread Reuben Thomas via Bug reports for Automake
I've had a look at the patch now, and found and fixed one bug.

However, an issue comes up for VPATH builds that needs a more thorough fix:
C files generated from Vala sources are shipped by "make dist" and hence
end up in srcdir, but in a VPATH build with a Vala compiler, they will be
in builddir. Unlike include files, you can't simply tell cc to look in two
places for the file it is to compile, so some other solution is needed.

There are various other cases in which I'm aware of generated sources being
shipped in tarballs, but they're all different sorts of special cases. For
example, configure is shipped, but it's always in srcdir. Other files, e.g.
man pages generated by help2man, have special rules to avoid regeneration,
but are not themselves used to generate further files. So, I couldn't see a
model to follow.

I can see a couple of options:

1. Treat valac-generated files as normal intermediate files, don't ship
them in make dist, and require a Vala compiler to build Vala sources. This
is not a huge deal, as almost all Vala programs will require the same
libraries as Vala itself, i.e. glib (and gio?).

2. Add build-aux/valac, a "missing" script that just copies a C file from
srcdir to builddir if it is newer than the corresponding Vala file, and
otherwise gives an error. Using the "missing" mechanism to add limited
functionality seems a fairly autotools-y thing to do.

Any other ideas?

-- 
https://rrt.sc3d.org


bug#13002: Updated, fixed patch

2020-10-28 Thread Reuben Thomas via Bug reports for Automake
I have taken Daniel Espinosa's patch and improved it so that it fixes all
the test failures. Some of the failures were actually left-over changes to
the tests required by Daniel's patch, which (correctly) considers the
primary location of C files generated by valac to be builddir, not srcdir.

One change in particular is quite awkward, and could do with other eyes, to
see if it's correct, and even if so, whether it could be simplified: the
additional check in line 5737 of automake.in which checks whether there's a
pre-built .c file in srcdir, and, if srcdir != builddir, copies the file
there if it is newer than the corresponding .vala file.

Having worked on this patch, I do wonder whether the hacks involved are
worth it. It seems to me there are two sensible options:

1. Add more support to automake for files that can be either generated or
distributed. (Have I overlooked support for this?)

2. Remove the support for distributing Vala projects as C files that do not
require a Vala compiler. The Vala compiler is portable and has much the
same dependencies as most Vala projects (that is, a C compiler and glib).

Without one of these, bugs and fragility in Vala support are likely to
continue.

-- 
https://rrt.sc3d.org
From 603373be839a87cb0ee97a16f4a243d86bbae72e Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 28 Oct 2020 09:42:21 +
Subject: [PATCH] Improve Vala support (closes #13002)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This commit is mostly work by Daniel Espinosa, but any bugs are Reuben
Thomas’s, who finished it off!

* NEWS: mention these changes.
* bin/automake.in: generated C files go in builddir, not srcdir.  Distribute
  the header files generated from VAPI files.
* t/vala-libs-distcheck.sh: new test for “make distcheck” of a Vala library.
* t/vala-libs-vpath.sh: new test for a VPATH build of a Vala library.
* t/vala-libs.sh: add local VAPIs used as external --package to test
* t/vala-{,non}-recursive-setup.sh: we need to make maintainer-clean at one
  point to remove stamp files to avoid confusing a VPATH build performed after
  a non-VPATH build.
* t/vala-{parallel,per-target-flags,recursive-setup,vpath}.sh: some test paths
  need changing to take into account that generated C files now go in
  builddir.
---
 NEWS  |   6 ++
 bin/automake.in   |  44 +---
 t/list-of-tests.mk|   2 +
 t/vala-libs-distcheck.sh  | 196 ++
 t/vala-libs-vpath.sh  | 108 +++
 t/vala-libs.sh|  49 +
 t/vala-non-recursive-setup.sh |   3 +-
 t/vala-parallel.sh|   4 +-
 t/vala-per-target-flags.sh|   4 +-
 t/vala-recursive-setup.sh |  18 ++--
 t/vala-vpath.sh   |  33 +++---
 11 files changed, 405 insertions(+), 62 deletions(-)
 create mode 100644 t/vala-libs-distcheck.sh
 create mode 100644 t/vala-libs-vpath.sh

diff --git a/NEWS b/NEWS
index 9c69e48d1..010cd3756 100644
--- a/NEWS
+++ b/NEWS
@@ -81,6 +81,10 @@ New in ?.?.?:
 
   - valac argument matching more precise, to avoid garbage in DIST_COMMON.
 
+  - Support for Vala in VPATH builds fixed so that both freshly-generated and
+distributed C files work, and operation is more reliable with or without
+an installed valac.
+
 * Distribution
 
   - new variable AM_DISTCHECK_DVI_TARGET, to allow overriding the
@@ -91,6 +95,8 @@ New in ?.?.?:
   - Removed function up_to_date_p in lib/Automake/FileUtils.pm.
 We believe this function is completely unused.
 
+  - Support for in-tree Vala libraries improved.
+
 
 
 New in 1.16.2:
diff --git a/bin/automake.in b/bin/automake.in
index a88b835a5..31c72382a 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5730,13 +5730,18 @@ sub lang_vala_finish_target
   my $c_file = $vala_file;
   if ($c_file =~ s/(.*)\.vala$/$1.c/)
 {
-  $c_file = "\$(srcdir)/$c_file";
-  $output_rules .= "$c_file: \$(srcdir)/${derived}_vala.stamp\n"
-. "\t\@if test -f \$@; then :; else rm -f \$(srcdir)/${derived}_vala.stamp; fi\n"
+  my $built_c_file = "\$(builddir)/$c_file";
+  my $built_dir = dirname $built_c_file;
+  my $base_c_file = basename $c_file;
+  $output_rules .= "$built_c_file: \$(builddir)/${derived}_vala.stamp\n"
+. "\t\@if test ! -f \$@ && test \$(srcdir) != \$(builddir) && test -n \"\$\$(find -L \$(srcdir)/$c_file -prune -newer \$(srcdir)/$vala_file)\"; then cp -p \$(srcdir)/$c_file $built_c_file; fi\n"
+. "\t\@if test -f \$@; then :; else rm -f \$(builddir)/${derived}_vala.stamp; fi\n"
 . "\t\@if test -f \$@; then :; else \\\n"
-. "\t  \$(MAKE) \$(AM_MAKEFLAGS) \$(srcdir)/${de

bug#13002: Updated, fixed patch

2020-10-28 Thread Reuben Thomas via Bug reports for Automake
On Wed, 28 Oct 2020 at 20:37, Karl Berry  wrote:

>
> As I wrote before, I strongly support this approach. Since the C file is
> derived, don't distribute it. Would that simplify the patch?
>

A patch to re-do Vala support would be a larger patch at this stage, though
overall it would certainly streamline Vala support in automake.

Also, being frank, removing "Vala-generated-C" support is the only way I
would offer to have anything to do with making such a patch, as (as far as
I can see) that route would be much simpler than retaining the current
support (even in deprecated form) while also putting in "normal" Vala
compiler support.

I also sympathise with the maintainers if they would rather not simply
remove the existing C-from-Vala support. I would offer the following
observation, though: as far as I can tell, most Vala developers are
migrating away from autotools (if they used it) to meson, along with the
rest of the GNOME ecosystem. Also, it's fairly straightforward to get old
versions of automake where needed. This could be used to argue in either
direction: on the one hand, replacing the current Vala support with
"normal" support would annoy a small proportion (committed automake users)
of a small user group (Vala programmers). On the other, it would benefit
few users.

It might be best then to make the decision based on automake's other users?
I for one would not be terribly happy as an automake maintainer at having
to keep Vala support working long-term, and to be honest, the patch I have
submitted, while fixing bugs in Vala support, will slightly add to the
maintenance burden.

My own use case is that I've rewritten GNU Zile (a small Emacs clone) in
Vala. Users building it will have to install glib anyway, and so while it
feels nice that they don't need a Vala compiler, as I said before, I don't
think in practice it's a big deal (even for a Zile user who doesn't care
about Vala, they're likely to be able to install valac easily using
whatever package manager they have).

-- 
https://rrt.sc3d.org


bug#13002: Updated, fixed patch

2020-10-28 Thread Reuben Thomas via Bug reports for Automake
To follow up clearly: if it were up to me, I'd install an acceptable
version of my patch, as it improves the status quo, and include it in the
next release. Then I'd think about whether it's possible to redo the Vala
support entirely.

-- 
https://rrt.sc3d.org


bug#13002: Updated, fixed patch

2020-11-01 Thread Reuben Thomas via Bug reports for Automake
On Fri, 30 Oct 2020 at 01:45, Karl Berry  wrote:

> install an acceptable version of my patch, as it improves the status
> quo, and include it in the next release. Then I'd think about
> whether it's possible to redo the Vala support entirely.
>
> Sounds sensible.
>
> I applied your change, but when running make distcheck (not make check)
> the new vala-libs-distcheck.sh test fails. Does that happen for you?
>

I get no errors.

Most of the other vala tests are skipped, with the message:
> vala-libs-vpath: skipped test: pkg-config m4 macros not found
>

I do not get these errors or skips: all the vala tests are run, and pass.

I confirm that I ran "make distcheck".

-- 
https://rrt.sc3d.org


bug#44422: AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-03 Thread Viktor Engelmann via Bug reports for Automake
I'm trying to port a project to docker and I'm also testing it on my
Raspberry Pi 3B+

when I *./configure* and *make* the project, it fails with this message

gcc: error: unrecognized -mcpu target: armv7l
gcc: note: valid arguments are: arm8 arm810 strongarm [...] cortex-a53 [...]
gcc: error: missing argument to '-march='

lscpu says this:

Architecture:    armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   4
Model name:  Cortex-A53
Stepping:    r0p4
CPU max MHz: 1200.
CPU min MHz: 600.
BogoMIPS:    38.40
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
idiva idi
 vt vfpd32 lpae evtstrm crc32

So it seems to me that AC_CANONICAL_HOST sets $host_cpu to armv7l,
although that is the Architecture and should be passed to -march
instead. -mcpu should get the Model name.

I couldn't get it to accept the --host=cpu-os-abi parameter, because
cortex-a35 contains a dash and that seems to confuse autoconf (that
produces the error message Invalid configuration
`cortex-a53-unknown-linux-gnueabihf': machine `cortex-a53-unknown' not
recognized). I did manage to compile with
--host=native-unknown-linux-gnueabihf, but I'd rather not define a fixed
ABI, because that would break the cross-platform compatibility of the
Dockerfile.

I'm using autoconf 2.69 from the docker base image "ubuntu:latest".






bug#44458: Regenerating testsuite-part.am when a new test case is added

2020-11-04 Thread Reuben Thomas via Bug reports for Automake
Or, bug #11347 again.

I just spent quite a while chasing down a test failure that was due to
testsuite-part.am not being remade when new tests were added.

I duly found bug #11347, which contains a rationale for not having
testsuite-part.am depend on all the tests.

However, the rationale doesn't seem to explain the reason for removing the
dependency on the *list* of tests. In particular, without depending on
list-of-tests.mk, the dependencies of new tests are not extracted
automatically, and so tests that depend on other tests can be run in the
wrong order (this was exactly my case: I had two new tests that both
depended on pkg-config).

Could the dependency of testsuite-part.am on list-of-tests.mk be reinstated?
-- 
https://rrt.sc3d.org


bug#44600: Automake does not make site.exp correctly when spaces in current path name.

2020-11-12 Thread Robert Menteer via Bug reports for Automake
If your current directory path contains a space then Automake creates an 
invalid site.exp file. The problem is in the following code placed into 
Makefile.in:

@echo 'set srcdir "$(srcdir)"' >>site.tmp
@echo "set objdir `pwd`" >>site.tmp

Note you do quote the source directory. If you were to quote the result of the 
pwd it would create a valid site.exp file:

@echo "set objdir \"`pwd`\"" >>site.tmp


> Begin forwarded message:
> 
> From: Jacob Bachmeyer 
> Subject: Re: bug#44580: DejaGnu runtest not found of site.exp exists
> Date: November 11, 2020 at 9:56:09 PM EST
> To: Robert Menteer , Robert Menteer via Bug-dejagnu 
> 
> Cc: 44580-d...@debbugs.gnu.org
> Reply-To: jcb62...@gmail.com
> 
> Robert Menteer via Bug-dejagnu via wrote:
>> What I found by running runtest by hand is it fails if the file site.ext 
>> exists.
> 
> Your site.exp file is invalid; this is a bug in Automake rather than a bug in 
> DejaGnu.  The version of Automake that produced the Makefile.in that you are 
> using mishandles filenames containing spaces.  Tcl requires a value 
> containing spaces to be properly quoted in a "set" command, and Automake is 
> producing a site.exp that does not contain those quotes for the objdir 
> variable.
> 
> An immediate workaround is to run `sed -e '/^set [^ ]*dir [^"]/{s/dir 
> /&"/;s/$/"/}' -i site.exp` (tested with GNU sed) to fix your site.exp file, 
> or to avoid building in a directory where the absolute filename contains 
> spaces.
> 
> Additionally, as of commit b53b22c29880f785ae5e9e1c72925d2583a4c76d (after 
> 1.6.2 was released) DejaGnu no longer loads site.exp when invoked with the 
> --version option.
> 
> Please try regenerating your Makefile.in with a newer Automake or report this 
> as a bug in Automake if you are already using the latest version.
> 
> I am closing this report as NOTOURBUG.
> 
> 
> -- Jacob

Original bug report to DejaGnu follows:
I have a Makefile created using the auto tools and it has a problem when making 
the ‘check’ target. The problem is the make file fails to verify the existence 
of runtest. The command used to test for the existence of runtest is:

if /bin/bash -c "runtest --version" > /dev/null 2>&1; then

What I found by running runtest by hand is it fails if the file site.ext 
exists. 

parallels@parallels-Parallels-Virtual-Platform:~/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite$ runtest --version
ERROR: tcl error sourcing /media/psf/FlDist/trunk/testsuite/site.exp.
wrong # args: should be "set varName ?newValue?"
while executing
"set objdir /home/parallels/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite"
(file "/media/psf/FlDist/trunk/testsuite/site.exp" line 5)
invoked from within
"source /media/psf/FlDist/trunk/testsuite/site.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /media/psf/FlDist/trunk/testsuite/site.exp"
invoked from within
"catch "uplevel #0 source $file""
parallels@parallels-Parallels-Virtual-Platform:~/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite$ rm site.exp
parallels@parallels-Parallels-Virtual-Platform:~/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite$ runtest --version
DejaGnu version 1.6.2
Expect version  5.45.4
Tcl version 8.6
parallels@parallels-Parallels-Virtual-Platform:~/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite$ uname -a
Linux parallels-Parallels-Virtual-Platform 5.4.0-42-generic #46-Ubuntu SMP Fri 
Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
parallels@parallels-Parallels-Virtual-Platform:~/Desktop/Parallels Shared 
Folders/FlDist/trunk/testsuite$ 



bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

2020-11-21 Thread Reuben Thomas via Bug reports for Automake
[CCing the bug, though this email wasn't addressed to it; looks like it
should have been, though!]

Indeed, the generated C file shouldn't be rebuilt; the existing distributed
C source file should be used.

I tried the test with v1.16.3 and it passed for me. Looking at the logs, I
found this line in Bruno's:

cc -DPACKAGE_NAME=\"vala-headers\" -DPACKAGE_TARNAME=\"vala-headers\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"vala-headers\ 1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"vala-headers\"
-DVERSION=\"1.0\" -I. -I../..-I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -MT quux.o -MD -MP -MF
.deps/quux.Tpo -c -o quux.o quux.c

whereas in mine it was:

cc -DPACKAGE_NAME=\"vala-headers\" -DPACKAGE_TARNAME=\"vala-headers\"
-DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"vala-headers\ 1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"vala-headers\"
-DVERSION=\"1.0\" -I. -I../..-isystem/usr/include/glib-2.0
-isystem/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -MT quux.o -MD
-MP -MF .deps/quux.Tpo -c -o quux.o ../../quux.c
Note the different path to the source file quux.c. Although, this does not
happen with zardoz.c (the source path is "zardoz.c" in the cwd for both
Bruno's log and mine), and that command succeeds for both of us.

This smells of race condition to me, and indeed if I unset MAKEFLAGS (I
usually have "-j 14") and run it again, then the path for zardoz.c is
../../zardoz.c. However, maybe it's not parallel building that's the
problem; could it be a problem with the test:

find -L $(srcdir)/quux.c -prune -newer $(srcdir)/quux.vala)

? The mtimes have only second resolution (set that way by tar) and so the
tests could come out either way.

The find rule could be fixed by making the test "not older" rather than
"newer" (leaving a different potential race condition, but a much rarer one
that would rely on very quick editing of the Vala source!). Specifically,
line 5737 of automake.in would become:

. "\t\@if test ! -f \$@ && test \$(srcdir) != \$(builddir) &&
test -n \"\$\$(find -L \$(srcdir)/$vala_file) -prune \! -newer
\$(srcdir)/$c_file\"; then cp -p \$(srcdir)/$c_file $built_c_file; fi\n"

But that doesn't seem to be the whole story, since in Bruno's case the
result was "file not found" whereas in my case it was "use a different
source file".

On Fri, 20 Nov 2020 at 23:22, Karl Berry  wrote:

> Reuben - any chance you can look into this vala failure?
>
> It seems that, (only) in the make distcheck done inside the test, the .c
> files are not remade from the .vala?
>
> Thanks,
> Karl
>
>
> Date: Fri, 20 Nov 2020 22:25:55 +0100
> From: Bruno Haible 
> Resent-From: Bruno Haible 
> Resent-CC: bug-automake@gnu.org
> Resent-Date: Fri, 20 Nov 2020 21:27:02 +
> Resent-Message-ID: 
> Resent-Sender: help-debb...@gnu.org
> To:  <44...@debbugs.gnu.org>
> Subject: bug#44772: 2 test failures in automake 1.16.3
>
> --1456002724-1605909332=:28818
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> On a glibc system, I'm seeing 2 test failures in automake 1.16.3:
> $ ./configure --prefix=/arch/x86_64-linux-gnu/gnu-inst-automake/1.16.3
> $ make
> $ make check
> ..
> FAIL: t/vala-headers.sh
> ..
> FAIL: t/vala-mix2.sh
> ..
>
> Find attached the log files (redacted for privacy reasons).
>
> vala and valac exist in /usr/bin.
>
> Bruno
>
> --1456002724-1605909332=:28818
> Content-Disposition: attachment; filename="vala-headers.log"
> Content-Type: text/x-log; charset="UTF-8"; name="vala-headers.log"
> Content-Transfer-Encoding: 7bit
>
> vala-headers: running pkg-config --version
> 0.29.1
> vala-headers: running valac --version
> Vala 0.30.1
> vala-headers: determine whether make is GNU make
> GNU Make 4.3
> Lizenz GPLv3+: GNU GPL Version 3 oder später <
> http://gnu.org/licenses/gpl.html>
> pkg-config version: 0.29.1
> dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
> dnl serial 11 (pkg-config-0.29.1)
> dnl
> dnl Copyright © 2004 Scott James Remnant .
> dnl Copyright © 2012-2015 Dan Nicholson 
> dnl
> dnl This program is free software; you can redistribute it and/or modify
> dnl it under the terms of the GNU General Public License as published by
> dnl the Free Software Foundation; either version 2 of the License, or
> dnl (at your option) any later version.
> dnl
> dnl This program is distributed in the hope that it will be useful, but
> 

bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

2020-11-21 Thread Reuben Thomas via Bug reports for Automake
On Sat, 21 Nov 2020 at 22:01, Karl Berry  wrote:

>
> By the way, I don't think that find command (or the cp -p for that
> matter) is excessively portable. But I guess we don't much care about
> crufty systems for vala support. --thanks, karl.
>

They are both using only POSIX-2008 features; these days I think that ought
to be good enough!

-- 
https://rrt.sc3d.org


bug#44845: Typo in manual

2020-11-24 Thread Reuben Thomas via Bug reports for Automake
The example filename "zardoc.c" in the Vala section should be "zardoz.c";
it doesn't really matter, but it is almost certainly a typo.

-- 
https://rrt.sc3d.org


bug#45013: Using a different tags program

2020-12-02 Thread Reuben Thomas via Bug reports for Automake
There doesn't seem to be a way for the user to configure a different ctags
program, unless I'm overlooking something? Passing "CTAGS=foo" to configure
has no effect; it seems that all one can do is pass "CTAGS=foo" to make
every time one runs "make tags".

-- 
https://rrt.sc3d.org


bug#45013: Using a different tags program

2020-12-03 Thread Reuben Thomas via Bug reports for Automake
On Thu, 3 Dec 2020 at 22:17, Karl Berry  wrote:

> Hi Reuben,
>
> There doesn't seem to be a way for the user to configure a different
> ctags program
>
> I don't know of anything to the contrary. So ... would you be up for
> making a patch to support it :)? Etags too, I guess? At least they seem
> to be treated in the same way. --thanks, karl.
>

Happy to look into it.

-- 
https://rrt.sc3d.org


bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

2020-12-04 Thread Reuben Thomas via Bug reports for Automake
I just noticed while updating to look at something else that a version of
my patch seems to have been applied, but with a misleading commit message.

It has my name on it, commit 7581ec208. But I don't think I had anything to
do with that commit!

The commit log says: "reverse -newer test". But it is not reversed: it is
changed from "C file newer than Vala file" to "C file not older than Vala
file".

If this change is documented elsewhere it might be worth noting this. It's
a little unfortunate that the git log will forever be misleading…

-- 
https://rrt.sc3d.org


bug#44772: [br...@clisp.org: bug#44772: 2 test failures in automake 1.16.3]

2020-12-04 Thread Reuben Thomas via Bug reports for Automake
On Fri, 4 Dec 2020 at 22:20, Karl Berry  wrote:

> You sent the proposed change in the bug report to Bruno, so I committed
> it in your name.
>

Sorry, I didn't mean to say I had nothing to do with the contents of the
patch, just that I didn't have anything to do with installing it. (And I
wasn't aware until just now that it had been installed, or I'd've said
something sooner!)

-- 
https://rrt.sc3d.org


bug#45013: Using a different tags program

2020-12-04 Thread Reuben Thomas via Bug reports for Automake
On Thu, 3 Dec 2020 at 22:26, Reuben Thomas  wrote:

>
> Happy to look into it.
>

I have looked into it and attach a trivial patch, which works nicely.

It's not obvious to me whether any documentation is required; I rather
expected that these variables would behave like others (CC, CXX etc.). I've
actually struggled to find other variables which work similarly. CYGPATH_W
does, but it's not documented at all.

-- 
https://rrt.sc3d.org
From 2ee7f693f6106d6f55064f4dcfc3b01dc1a53bde Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Fri, 4 Dec 2020 23:11:13 +
Subject: [PATCH] tags: add support for CTAGS, ETAGS and CSCOPE to be set by
 ./configure

This change fixes https://bugs.gnu.org/45013

* lib/am/tags.m4: add default settings and AC_SUBST calls for the variables
  `CTAGS', `ETAGS' and `CSCOPE'.
* m4/init.m4: remove default settings of the above variables.
---
 lib/am/tags.am |  3 ---
 m4/init.m4 | 14 ++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/lib/am/tags.am b/lib/am/tags.am
index a485ff840..c1ec37772 100644
--- a/lib/am/tags.am
+++ b/lib/am/tags.am
@@ -45,7 +45,6 @@ ID: $(am__tagged_files)
 ## TAGS.  ##
 ## -- ##
 
-ETAGS = etags
 .PHONY: TAGS tags
 if %?SUBDIRS%
 AM_RECURSIVE_TARGETS += TAGS
@@ -101,7 +100,6 @@ tags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files)
 ## vi-style tags.  ##
 ## --- ##
 
-CTAGS = ctags
 .PHONY: CTAGS ctags
 if %?SUBDIRS%
 AM_RECURSIVE_TARGETS += CTAGS
@@ -136,7 +134,6 @@ GTAGS:
 ## --- ##
 
 if %?TOPDIR_P%
-CSCOPE = cscope
 .PHONY: cscope clean-cscope
 AM_RECURSIVE_TARGETS += cscope
 cscope: cscope.files
diff --git a/m4/init.m4 b/m4/init.m4
index ba73676c1..f82d756c2 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -116,6 +116,20 @@ AC_PROVIDE_IFELSE([AC_PROG_OBJCXX],
 		  [m4_define([AC_PROG_OBJCXX],
 			 m4_defn([AC_PROG_OBJCXX])[_AM_DEPENDENCIES([OBJCXX])])])dnl
 ])
+# Variables for tags utilities; see am/tags.am
+if test -z "$CTAGS"; then
+  CTAGS=ctags
+fi
+AC_SUBST([CTAGS])
+if test -z "$ETAGS"; then
+  ETAGS=etags
+fi
+AC_SUBST([ETAGS])
+if test -z "$CSCOPE"; then
+  CSCOPE=cscope
+fi
+AC_SUBST([CSCOPE])
+
 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
-- 
2.25.1



bug#46030: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__)); "

2021-01-22 Thread mathias . steiger--- via Bug reports for Automake
Subject: obscure bug "extern void free (void *__ptr) __attribute__ 
((__nothrow__ , __leaf__));"


Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt 
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' 
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' 
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux C1MPAQ 5.10.7-arch1-1 #1 SMP PREEMPT Wed, 13 Jan 
2021 12:02:01 + x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1)
Patch Level: 4
Release Status: release


Description:


An Autoconf configure script from Libreelec does fail, because some file 
it generated does unexpectedly contain output from some command it 
called in an if-statement that had output directed to >& /dev/null . 
Various alterations to the script do produce strange outcomes. Sometimes 
it avoids the bug, sometimes it will result in the line "extern void 
free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));" to be 
inserted into the file in addition to the behavior. See "Repeat-By" for 
more details.


A great mystery is the origin of the line "extern void free ...". A grep 
on the Libreelec files doesn't return anything. I could only find it in 
/usr/include/ruby-2.7.0/x86_64-linux/rb_mjit_min_header-2.7.2.h . But 
then removing that file still resulted in the the line being wrongfully 
inserted.


In bash-5.0.018-2 the bug does not appear.

I already reported this to bug-b...@gnu.org , but I was advised that 
this bug should be handled by autoconf.


It looks to me like a pointer overflow, which causes bash to write to 
the wrong buffer.


Strace: https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd


Repeat-By:


git clone https://github.com/LibreELEC/LibreELEC.tv # 
0582177d5eb0ec37d88dfa197908d3b03d047863

cd LibreELEC.tv
ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX ./scripts/build linux
    -> the build fails after a minute at package "ccache" in the 
Autoconfig step due to wrongful insertion of silenced command output 
into file config.status at line 533

In: build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/configure
Go to line 6532: if diff "$cache_file" confcache >/dev/null 2>&1; then 
:; else
Hint: $cache_file is always /dev/null , hence the if-statement will 
evaluate false


This diff command is the source of the insertion in 
build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/config.status 
:

        0a1,97:
        > # This file is a shell script that caches the results of 
configure
        > # tests run on this system so they can be shared between 
configure

        ...

Remove the line and the corresponding "fi" that closes the if-statement
    -> script inserts "extern void free ..." instead into 
./config.status at line 533


Replace line with: if diff "$cache_file" confcache >& /tmp/nothing; then 
:; else
    -> script inserts not only "extern void free ..." in config.status, 
but also the following into /tmp/nothing at the top in addition to the 
output:

        1c1,97
        < extern void free (void *__ptr) __attribute__ ((__nothrow__ , 
__leaf__));

        ---
        > # This file is a shell script that caches the results of 
configure

        ...

Replace line with if cat /tmp/nothing >& /dev/null; then :; else
    -> script inserts content of /tmp/nothing into ./config.status at 
line 533


Replace line with if false; then :; else # or some other random command, 
like "ls >& /dev/null"

    -> script works

Content of /tmp/nothing (all characters are exact part of the file):
1c1,97
< extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));
---
> # This file is a shell script that caches the results of configure
> # tests run on this system so they can be shared between configure
> # scripts and configure runs, see configure's option --config-cache.
> # It is not useful on other systems.  If it contains results you don't
> # want to keep, you may remove or edit it.
> #
> # config.status only pays attention to the cache file if you give it
> # the --recheck option to rerun configure.
> #
> # `ac_cv_env_foo' variables (set or unset) will be overridden when
> # loading this file, other *unset* `ac_cv_foo' will be assigned the
> # following values.
>
> ac_cv_build=${ac_cv_build=x86_64-pc-linux-gnu}
> ac_cv_c_bigendian=${ac_cv_c_bigendian=no}
> ac_cv_c_compiler_clang=${ac_cv_c_compiler_clang=no}
> ac_cv_c_compiler_gnu=${ac_cv_c_compiler_gnu=yes}
> ac_cv_c_extern_inline=${ac_cv_c_extern_inline=no}
> ac_cv_c_inline=${ac_cv_c_inline=inline}
> ac_cv_env_CC_set=set
> ac_cv_env_CC_value=/bin/gcc
> ac_cv_env_CFLAGS_set=set
> ac_cv_env_CFLAGS_value='-march=native -O2 -Wall -pipe 
-I/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/include 
-Wno-format-security'

> ac_cv_env_CPPFLAGS_set=set
> a

bug#46030: problem is resolved - please close bug

2021-01-22 Thread mathias . steiger--- via Bug reports for Automake



The source of the problem is that /dev/null was a regular file on my system.

I checked against this before filing the bug, but not in proper ways.

I am sorry for the inconvenience.






bug#46744: Make automake ourput reproducible

2021-02-24 Thread Josef Möllers via Bug reports for Automake
Hi,

We rely on builds to be reproducible.

The PERL script bin/automake.in calls the perl function "keys" at
several places. The returned list, unfortunately, changes between
invocation of the script. "sort"ing the returned list makes the process
reproducible again.

Attached is a patch courtesy of Dirk Müller.

Josef

--- automake-1.16.3/bin/automake.in
+++ automake-1.16.3/bin/automake.in
@@ -2388,7 +2388,7 @@
   $var->requires_variables ("\@${lt}LIBOBJS\@ used", $lt . 'LIBOBJS')
 if ! keys %libsources;

-  foreach my $iter (keys %libsources)
+  foreach my $iter (sort keys %libsources)
 {
   my $dir = '';
   if ($iter =~ /^(.*)(\.[cly])$/)
@@ -4692,7 +4692,7 @@
 	 DIST_CLEAN, [],
 	 MAINTAINER_CLEAN, []);

-  foreach my $file (keys %clean_files)
+  foreach my $file (sort keys %clean_files)
 {
   my $when = $clean_files{$file};
   prog_error 'invalid entry in %clean_files'
@@ -4762,7 +4762,7 @@
 	   . "not 'install-hook'");

   # Install the -local hooks.
-  foreach (keys %dependencies)
+  foreach (sort keys %dependencies)
 {
   # Hooks are installed on the -am targets.
   s/-am$// or next;
@@ -4784,7 +4784,7 @@
 }

   # All the required targets are phony.
-  depend ('.PHONY', keys %required_targets);
+  depend ('.PHONY', sort keys %required_targets);

   # Actually output gathered targets.
   foreach (sort target_cmp keys %dependencies)
@@ -5260,7 +5260,7 @@
   # has a precise meaning for AC_CONFIG_FILES and so on.
   $traces .= join (' ',
 		   map { "--trace=$_" . ':\$f:\$l::\$d::\$n::\${::}%' }
-		   (keys %traced));
+		   (sort keys %traced));

   verb "running WARNINGS=$ENV{WARNINGS} $traces";
   my $tracefh = new Automake::XFile ("$traces $filename |");
@@ -5831,7 +5831,7 @@
 {
   my ($self) = @_;

-  foreach my $prog (keys %known_programs)
+  foreach my $prog (sort keys %known_programs)
 {
   lang_vala_finish_target ($self, $prog);
 }


bug#47848: aclocal fails with "error: too many loops"

2021-04-17 Thread Eric Gallager via Bug reports for Automake
Hi, I have recently been trying to update my fork of the
magicseteditor project, which can be found here:
https://github.com/cooljeanius/magicseteditor
At first, autoconf told me:
configure.ac:109: warning: AX_CXX_COMPILE_STDCXX_0X is obsolete; use
AX_CXX_COMPILE_STDCXX_11 instead
...so I followed its recommendation and updated
AX_CXX_COMPILE_STDCXX_0X to AX_CXX_COMPILE_STDCXX_11, and
AX_CXX_HEADER_STDCXX_0X to AX_CXX_HEADER_STDCXX_11, and once I had
done that, it failed with this message instead:
$ autoreconf -fvi -Wall
autoreconf: export WARNINGS=all
autoreconf: Entering directory '.'
autoreconf: running: autopoint --force
autoreconf: running: aclocal --force -I m4 --install
aclocal: installing 'm4/ax_cxx_compile_stdcxx.m4' from
'/opt/local/share/aclocal/ax_cxx_compile_stdcxx.m4'
aclocal: installing 'm4/ax_cxx_compile_stdcxx_11.m4' from
'/opt/local/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_require_defined.m4' from
'/opt/local/share/aclocal/ax_require_defined.m4'
aclocal: error: too many loops
aclocal: Please contact .
 at /opt/local/share/automake-1.16/Automake/Channels.pm line 655.
Automake::Channels::msg("automake", "", "too many loops") called
at /opt/local/share/automake-1.16/Automake/ChannelDefs.pm line 226
Automake::ChannelDefs::prog_error("too many loops") called at
/opt/local/bin/aclocal line 1187
autoreconf: error: aclocal failed with exit status: 255
$

Since it said to report this here, that is what I am doing. I am using
automake 1.16.3 as installed by MacPorts. Any idea what's going on?
Thanks,
Eric Gallager





bug#48113: Module suggestion: timeout

2021-04-30 Thread Simon Josefsson via Bug reports for Automake
Bruno Haible  writes:

> So, I don't think the "let's treat timeout like valgrind" approach is going
> to work. Instead, you need to design a way to deal with timeouts, 
> independently.

Hi!  I think Marc's request for functionality to introduce timeouts for
self-tests is a good one.  However I reach the same conclusion as Bruno,
that having a module like valgrind-tests is probably not the best way to
solve it.  To me, having a timeout seems like an essential feature of a
self-test framework.  I know automake isn't primarily a self-test
framework, but it has concepts for it and the test framework has been
improved significantly over the years, so I think adding a timeout
functionality to automake makes sense.  What do bug-automake people
think?

The functionality could be conditioned on the coreutils 'timeout' tool,
and if that tool exists, and appears to work, running all self-tests
under that tool could be done automatically.  The default self-test
timeout be quite generous (say 17 hours?) but it should be easy to
modify both by end-user and project developer.  If we want to be
conservative, the functionality could be opt-in initially, and then
after a few years become the default behaviour.

Thoughts?

/Simon


signature.asc
Description: PGP signature


bug#48113: Module suggestion: timeout

2021-04-30 Thread Simon Josefsson via Bug reports for Automake
Marc Nieper-Wißkirchen  writes:

> Moreover, use cases for a baked-in timeout are not restricted to tests. For
> example, I may want to restrict the build time of certain components in
> situations where a logical error may lead to infinite build times (a simple
> example is that of a Scheme compiler used as a build tool; thanks to
> Turing-completeness of Scheme macros, such a build may not terminate).

This makes me believe even stronger that the functionality ought to be
provided by automake natively -- it seems the desired functionality is
not only timeouts for self-tests but timeouts for all operations.

Implementing this for self-tests in automake would probably be quite
simple, but implementing it for all operations is probably more
complicated.  Maybe it should be two separate features.  I have wanted
timeouts for self-tests but rarely for building.  If the second is more
complicated to implement, maybe starting with the first will be
sufficient and useful.

/Simon


signature.asc
Description: PGP signature


bug#48113: Module suggestion: timeout

2021-05-02 Thread Simon Josefsson via Bug reports for Automake
severity 48113 wishlist
retitle 48113 Self-test timeout functionality
thanks

Karl Berry  writes:

> What do bug-automake people think?
>
> For myself, I have no objection to sprinkling timeout commands through
> the Automake test infrastructure wherever appropriate. It's not ever
> going to rise to the top of my own list of things to do, though, so if
> it's going to happen, you or someone will have to write the patch.
>
> Of course I don't speak for Jim, but from what he's said in the past,
> I suspect he is in a similar situation.

Thanks for confirming that it isn't an obviously bad idea.  Tagging this
as a wishlist bug, and improving the bug title a bit.

> No one else has come forward to work on Automake, despite my plea
> (https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html),
> so I guess that's where we are.

Ah right -- I'll see if I can help in any way, but will respond
separately.

> the functionality could be opt-in initially, 
>
> Certainly.
>
> and then after a few years become the default behaviour.
>
> Personally, I think it should be opt-in forever. People could easily
> have test suites that need to run for days. I prefer not to
> unnecessarily break compatibility.

Yes, I probably agree with this -- chosing the default timeout setting
is difficult as it will most likely just cause problems for some people
with long-running tests, and not solve the initial problem for some
other people (that have small projects and a timeout of 5 minutes is
what you want).  Better leave this up the each project to decide.

/Simon


signature.asc
Description: PGP signature


bug#47848: aclocal fails with "error: too many loops"

2021-05-09 Thread Eric Gallager via Bug reports for Automake
On Sun, May 9, 2021 at 9:28 PM Karl Berry  wrote:
>
> Ei Eric,
>
> Automake::ChannelDefs::prog_error("too many loops") called at
> /opt/local/bin/aclocal line 1187
>
> I've never seen that error before. The comment in aclocal where the
> check is done says:
>
> # We may have to rerun aclocal if some file have been installed, but
> # it should not happen more than once.
>
> So, hmm.
>
> https://github.com/cooljeanius/magicseteditor
> ...
> automake 1.16.3 as installed by MacPorts. Any idea what's going on?
>
> Nothing springs to mind, sorry.
>
> Is it reproducible? Any chance you can cut down your configure.ac and
> project to something smaller? Else I guess I can try taking your project
> and making the same change (eventually).
>
> Thanks for the report. --karl
>

Nope, I can't seem to reproduce it, unfortunately; after trying again
more recently, it started working again, and I'm not sure what might
have changed in my environment to cause that to happen... sorry, this
can be closed...
Eric





bug#49901: Bug in build c-ares [too many loops]

2021-08-17 Thread Brad House via Bug reports for Automake
I'm one of the maintainers of the c-ares project at 
https://github.com/c-ares/c-ares and have had a couple of users report 
this issue.  At first glance it appears to be an issue introduced 
between automake 1.16.1 and 1.16.3.


I actually did some testing on MacOS 11.4 with automake 1.16.4 and can 
reproduce the issue.  Whereas 1.16.1 on CentOS 8 it works fine. I 
haven't tried backing off automake to 1.16.1 on MacOS.


Reported issues for c-ares are here:

https://github.com/c-ares/c-ares/issues/409
https://github.com/c-ares/c-ares/issues/416

Rerunning autoreconf -fi appears to succeed, but then when building 
after configure, make immediately throws an error so it clearly didn't 
actually work.


The autotools build hasn't been touched in years short of a code 
reorganization a year or so ago.


I haven't had time yet to investigate if there is an older version of 
c-ares that works with the newer automake to try to figure out a trigger.


I know this isn't much information to go off of, but the user just told 
me they had opened this issue so I wanted to chime in as I'm not sure 
when I'll have a chance to investigate further.


-Brad






bug#49901: Bug in build c-ares [too many loops]

2021-08-17 Thread Brad House via Bug reports for Automake




On 8/17/21 1:06 PM, Nick Bowler wrote:

On 2021-08-17, Brad House via Bug reports for Automake
 wrote:

I'm one of the maintainers of the c-ares project at
https://github.com/c-ares/c-ares and have had a couple of users report
this issue.

I took a quick glance and I found this:

   https://github.com/c-ares/c-ares/blob/main/m4/zz60-xc-ovr.m4

which is redefining autoconf-supplied macros (AC_CONFIG_MACRO_DIR) and
is almost certainly the cause of your problem.  I suggest simply not
doing that, and aclocal will probably work as expected.  Just delete
this file and delete the XC_OVR_ZZ60 line from configure.ac and I
expect your aclocal failure will go away.



If you really need something like this to support bootstrapping with
Autoconf 2.57 (which is getting close to 20 years old now!), I suggest
you find another solution that doesn't involve redefining the internals
on newer Autoconf versions.



Thanks for taking a glance at this, unfortunately it didn't correct the 
issue:


bhouse:c-ares-master bhouse$ autoreconf -fiv
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4 --install
aclocal: installing 'm4/ax_ac_append_to_file.m4' from 
'/usr/local/share/aclocal/ax_ac_append_to_file.m4'
aclocal: installing 'm4/ax_ac_print_to_file.m4' from 
'/usr/local/share/aclocal/ax_ac_print_to_file.m4'
aclocal: installing 'm4/ax_add_am_macro_static.m4' from 
'/usr/local/share/aclocal/ax_add_am_macro_static.m4'
aclocal: installing 'm4/ax_am_macros_static.m4' from 
'/usr/local/share/aclocal/ax_am_macros_static.m4'
aclocal: installing 'm4/ax_check_gnu_make.m4' from 
'/usr/local/share/aclocal/ax_check_gnu_make.m4'
aclocal: overwriting 'm4/ax_code_coverage.m4' with 
'/usr/local/share/aclocal/ax_code_coverage.m4'
aclocal: installing 'm4/ax_cxx_compile_stdcxx.m4' from 
'/usr/local/share/aclocal/ax_cxx_compile_stdcxx.m4'
aclocal: overwriting 'm4/ax_cxx_compile_stdcxx_11.m4' with 
'/usr/local/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_file_escapes.m4' from 
'/usr/local/share/aclocal/ax_file_escapes.m4'
aclocal: installing 'm4/libtool.m4' from 
'/usr/local/share/aclocal/libtool.m4'
aclocal: installing 'm4/ltoptions.m4' from 
'/usr/local/share/aclocal/ltoptions.m4'
aclocal: installing 'm4/ltsugar.m4' from 
'/usr/local/share/aclocal/ltsugar.m4'
aclocal: installing 'm4/ltversion.m4' from 
'/usr/local/share/aclocal/ltversion.m4'
aclocal: installing 'm4/lt~obsolete.m4' from 
'/usr/local/share/aclocal/lt~obsolete.m4'
aclocal: installing 'm4/ax_require_defined.m4' from 
'/usr/local/share/aclocal/ax_require_defined.m4'

aclocal: error: too many loops
aclocal: Please contact .
 at 
/usr/local/Cellar/automake/1.16.4/share/automake-1.16/Automake/Channels.pm 
line 655.
    Automake::Channels::msg("automake", "", "too many loops") called at 
/usr/local/Cellar/automake/1.16.4/share/automake-1.16/Automake/ChannelDefs.pm 
line 226
    Automake::ChannelDefs::prog_error("too many loops") called at 
/usr/local/bin/aclocal line 1187

autoreconf: error: aclocal failed with exit status: 255








bug#49901: Bug in build c-ares [too many loops]

2021-08-17 Thread Brad House via Bug reports for Automake

This ended up being the fix to needing to run autoreconf -fi multiple times:
https://github.com/c-ares/c-ares/commit/e73fb47

Which appears to not be specific to c-ares as we got the logic from:
https://github.com/fenrus75/powertop/pull/82
https://bugzilla.redhat.com/show_bug.cgi?id=1835638

After that, there is also the issue that the newer ax_code_coverage.m4 
that is automatically pulled in is not API compatible as it removes 
@CODE_COVERAGE_RULES@ which isn't too friendly, plus adds a slew of 
additional .m4 dependencies that had to be imported.


And then finally, there is actually a bug in the latest 
ax_code_coverage.m4 that quotes AC_MSG_ERROR() which causes older 
autoconf/automake versions to barf.

https://github.com/c-ares/c-ares/commit/3883d99b05a845e4b40fc25c43ca83db70f4f20f#diff-fe38622a6c742be1bb93e6e65a0728f659114b3dc8d88172cb8844fa963418f9

I'm not sure where to report the last 2 issues.







bug#50924: automake-1.16: error: unrequested trace '$n'

2021-09-30 Thread Filipp Uskov via Bug reports for Automake

I download  https://github.com/crosstool-ng/crosstool-ng.git and try to build 
it under cygwin and get error automake-1.16: error: unrequested trace '$n'
 
(1j0/cygdrive/c/Users/feelus/_repos/_foreign)--0---(feelus@feelus-PC@23:53)
[503] $ git clone --depth 1 --config core.autocrlf=input 
https://github.com/crosstool-ng/crosstool-ng.git
Клонирование в «crosstool-ng»…
remote: Enumerating objects: 1770, done.
remote: Counting objects: 100% (1770/1770), done.
remote: Compressing objects: 100% (1548/1548), done.
remote: Total 1770 (delta 363), reused 1117 (delta 162), pack-reused 0
Получение объектов: 100% (1770/1770), 2.23 МиБ | 1.09 МиБ/с, готово.
Определение изменений: 100% (363/363), готово.
Updating files: 100% (1821/1821), готово.
 
(1j0/cygdrive/c/Users/feelus/_repos/_foreign)--0---(feelus@feelus-PC@23:53)
[504] $ cd crosstool-ng
bash-completion  config  contrib  debian  docs  kconfig  licenses.d  m4  
maintainer  packages  samples  scripts  testing  bootstrap  configure.ac  
COPYING  ct-ng.in  issue_template.md  LICENSE  Makefile.am  paths.sh.in  
README.md  TODO
 
(1j0/cygdrive/c/Users/feelus/_repos/_foreign/crosstool-ng)--0---(feelus@feelus-PC@23:53)
[505] $ ./bootstrap
INFO  :: *** Generating package version descriptions
INFO  :: Master packages: android-ndk autoconf automake avr-libc binutils bison 
cloog dtc duma elf2flt expat gcc gdb gettext glibc glibc-ports gmp gnuprumcu 
isl libelf libiconv libtool linux ltrace m4 make mingw-w64 moxiebox mpc mpfr 
musl ncurses newlib newlib-nano picolibc strace uClibc zlib
INFO  :: Generating 'config/versions/android-ndk.in'
INFO  :: Generating 'config/versions/autoconf.in'
INFO  :: Generating 'config/versions/automake.in'
INFO  :: Generating 'config/versions/avr-libc.in'
INFO  :: Generating 'config/versions/binutils.in'
INFO  :: Generating 'config/versions/bison.in'
INFO  :: Generating 'config/versions/cloog.in'
INFO  :: Generating 'config/versions/dtc.in'
INFO  :: Generating 'config/versions/duma.in'
INFO  :: Generating 'config/versions/elf2flt.in'
INFO  :: Generating 'config/versions/expat.in'
INFO  :: Generating 'config/versions/gcc.in'
INFO  :: Generating 'config/versions/gdb.in'
INFO  :: Generating 'config/versions/gettext.in'
INFO  :: Generating 'config/versions/glibc.in'
INFO  :: Generating 'config/versions/glibc-ports.in'
INFO  :: Generating 'config/versions/gmp.in'
INFO  :: Generating 'config/versions/gnuprumcu.in'
INFO  :: Generating 'config/versions/isl.in'
INFO  :: Generating 'config/versions/libelf.in'
INFO  :: Generating 'config/versions/libiconv.in'
INFO  :: Generating 'config/versions/libtool.in'
INFO  :: Generating 'config/versions/linux.in'
INFO  :: Generating 'config/versions/ltrace.in'
INFO  :: Generating 'config/versions/m4.in'
INFO  :: Generating 'config/versions/make.in'
INFO  :: Generating 'config/versions/mingw-w64.in'
INFO  :: Generating 'config/versions/moxiebox.in'
INFO  :: Generating 'config/versions/mpc.in'
INFO  :: Generating 'config/versions/mpfr.in'
INFO  :: Generating 'config/versions/musl.in'
INFO  :: Generating 'config/versions/ncurses.in'
INFO  :: Generating 'config/versions/newlib.in'
INFO  :: Generating 'config/versions/newlib-nano.in'
INFO  :: Generating 'config/versions/picolibc.in'
INFO  :: Generating 'config/versions/strace.in'
INFO  :: Generating 'config/versions/uClibc.in'
INFO  :: Generating 'config/versions/zlib.in'
INFO  :: *** Generating menu/choice selections
INFO  :: Generating arch.in (choice)
INFO  :: Generating kernel.in (choice)
INFO  :: Generating cc.in (choice)
INFO  :: Generating binutils.in (choice)
INFO  :: Generating libc.in (choice)
INFO  :: Generating debug.in (menu)
INFO  :: Generating comp_tools.in (menu)
INFO  :: Generating comp_libs.in (menu)
INFO  :: *** Gathering the list of data files to install
INFO  :: *** Running autoreconf
automake-1.16: error: unrequested trace '$n'
automake-1.16: Please contact .
 at /usr/share/automake-1.16/Automake/Channels.pm line 662,  line 1.
    Automake::Channels::msg("automake", "", "unrequested trace '\$n'") 
called at /usr/share/automake-1.16/Automake/ChannelDefs.pm line 212
    Automake::ChannelDefs::prog_error("unrequested trace '\$n'") called at 
/usr/bin/automake-1.16 line 5271
    Automake::scan_autoconf_traces("configure.ac") called at 
/usr/bin/automake-1.16 line 5530
    Automake::scan_autoconf_files() called at /usr/bin/automake-1.16 line 
8357
autoreconf-2.69: automake failed with exit status: 29
INFO  :: *** Done!
 
(1j0/cygdrive/c/Users/feelus/_repos/_foreign/crosstool-ng)--0---(feelus@feelus-PC@00:15)
[506] $ ls
autom4te.cache   config   debian  kconfig m4  packages  scripts  
aclocal.m4  config.h.in  configure.ac  ct-ng.in   LICENSE  
paths.sh.in  TODO
bash-completion  contrib  docs    licenses.d  maintainer  samples   testing  
bootstrap   configure    COPYING   issue_template.md  Makefile.am  
README.md    verbatim-data.mk
 
 
 
--
Filipp

bug#14959: automake 1.14 failure on OS X 10.6.8: fort5

2022-02-20 Thread Diab Jerius via Bug reports for Automake

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

On Fri, 26 Jul 2013 11:32:18 -0400, Diab Jerius wrote:

The fort5 test fails on Mac OS X 10.6.8.

the failing part of the log:

/bin/sh ./libtool  --tag=FC   --mode=link gfortran  -g -O2   -o libhello.la 
-rpath /usr/local/lib foo.lo bar.lo libgoodbye.la
libtool: link: gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
.libs/libhello.0.dylib  .libs/foo.o .libs/bar.o   
-Wl,-force_load,./.libs/libgoodbye.a   -O2   -install_name  
/usr/local/lib/libhello.0.dylib -compatibility_version 1 -current_version 1.0 
-Wl,-single_module
/usr/bin/libtool: unknown option character `f' in: -force_load
Usage: /usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] 
[-arch_only arch] [-sacLT]
Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only 
arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] 
[-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table 
] [-seg_addr_table_filename ] [-all_load] 
[-noall_load]
make: *** [libhello.la] Error 1

i can't explain why it's running /usr/bin/libtool in the first place.
the test generated & bundled a local copy of libtool and it is using
that.  is the libtool on macOS falling back to the /usr/bin/libtool ??


Hi,

Thanks for looking at this, but I'm afraid I won't be able to reproduce 
this after this period of time. Mac OS X has changed dramatically since 
2013, and I don't have access to anything that old.


Diab







bug#60607: Making dvi target do nothing

2023-01-06 Thread Reuben Thomas via Bug reports for Automake
I'm using automake 1.16.5. The advice about how to disable the "dvi" target
doesn't seem to work.

In the manual it says:

   To make ‘dvi’ into a do-nothing target, see the example for
‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::.

If I have:

EMPTY_AUTOMAKE_TARGETS = dvi
.PHONY: $(EMPTY_AUTOMAKE_TARGETS)
$(EMPTY_AUTOMAKE_TARGETS):

in my Makefile.am, then "TEXI2DVI" is still run by "make distcheck".

If I instead have:

dvi:

then it is not.

-- 
https://rrt.sc3d.org


bug#60607: Making dvi target do nothing

2023-01-07 Thread Reuben Thomas via Bug reports for Automake
On Sat, 7 Jan 2023 at 08:46, Nick Bowler  wrote:

>
> This example in the manual is talking about writing a custom
> Makefile, *without* using Automake, that you want to recurse
> into using Automake's SUBDIRS feature.
>

Aha! Thanks for pointing this out. I think the manual is misleading in
another place, because I got to this section via this cross-reference:

   To make ‘dvi’ into a do-nothing target, see the example for
‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::.

This is in the section "dvi and distcheck", which AFAICT is about
Makefile.am, not third-party Makefiles.

> If I instead have:
> >
> > dvi:
> >
> > then it is not.
>
> This is right way to override the dvi target that would
> otherwise be generated by Automake.
>

So it seems that this is what the section "dvi and distcheck" should advise.

-- 
https://rrt.sc3d.org


bug#60607: Making dvi target do nothing

2023-01-08 Thread Reuben Thomas via Bug reports for Automake
On Sun, 8 Jan 2023 at 00:23, Karl Berry  wrote:

> How does this change to the doc look? --thanks, karl.
>

Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the
assessment of technical accuracy to others.)

-- 
https://rrt.sc3d.org


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

2023-01-23 Thread Bert Wesarg via Bug reports for Automake
On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger  wrote:
>
> 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.

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

Bert

> -mike
>
>
>





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

2023-01-23 Thread Bert Wesarg via Bug reports for Automake
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.

>
> FYI, with my Autoconf hat on, I will not be inclined to take patches that 
> hardcode "ANSI" terminal control codes.  $TERM must be honored in detail.  
> The easiest way to do that is probably to probe for the existence of the 
> `tput` command and then use that to set shell variables with all the 
> necessary control codes.  When working on patches for Automake, also keep in 
> mind that $TERM might change between "./configure" and "make".

It reuses the color setting code from lib/am/check.am, which is
already in use. And autoconf has its own logic copied into m4sh.m4. So
the decision is independent

Bert





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

2023-01-23 Thread Bert Wesarg via Bug reports for Automake
Full disclosure: the most controversial change in behavior is probably
the removal of batch processing files at install time, or maybe also
other times, to get for each file a colored silent rule output.. JAVAC
is the exception, as all .java files needs to passed at once to the
compiler.

On Tue, Jan 24, 2023 at 7:06 AM Bert Wesarg  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.
>
> >
> > FYI, with my Autoconf hat on, I will not be inclined to take patches that 
> > hardcode "ANSI" terminal control codes.  $TERM must be honored in detail.  
> > The easiest way to do that is probably to probe for the existence of the 
> > `tput` command and then use that to set shell variables with all the 
> > necessary control codes.  When working on patches for Automake, also keep 
> > in mind that $TERM might change between "./configure" and "make".
>
> It reuses the color setting code from lib/am/check.am, which is
> already in use. And autoconf has its own logic copied into m4sh.m4. So
> the decision is independent
>
> Bert





bug#61088: How to make AM_EXTRA_RECURSIVE_TARGETS skip some directories?

2023-01-26 Thread Reuben Thomas via Bug reports for Automake
I have an automake project with a 'po' subdirectory whose contents,
including Makefile.in.in, is entirely generated by gettext. 'po' is in my
top level Makefile.am's SUBDIRS.

When I add an AM_EXTRA_RECURSIVE_TARGETS entry, say 'foo', automake tries
to recurse into po and 'make foo', and of course this doesn't work.

Is there a way around this?

-- 
https://rrt.sc3d.org


bug#61088: Problem solved

2023-01-28 Thread Reuben Thomas via Bug reports for Automake
I found the "Rules-*" feature of gettext to do this; sorry for the noise!

-- 
https://rrt.sc3d.org


bug#61278: Automake warns about LDFLAGS for defined library

2023-02-04 Thread Reuben Thomas via Bug reports for Automake
Using automake 1.16.5, in my Makefile.am, I have the following lines:

noinst_LTLIBRARIES = liba2ps.la
liba2ps_la_LDFLAGS = $(LIBGC_LIBS)
liba2ps_la_SOURCES = $(liba2pssources) $(libitsources) $(mylibitsources)
liba2ps_la_LIBADD = ../lib/libgnu.la $(LIBINTL) $(LIBSOCKET)
$(GETHOSTNAME_LIB)

noinst_LIBRARIES = libnowarnings.a
libnowarnings_a_CFLAGS = $(LIBGC_FLAGS)
libnowarnings_a_LDFLAGS = $(LIBGC_LIBS)
libnowarnings_a_SOURCES = fonts.l lexppd.l parseppd.y regex.c regex.h
confg.c confg.h

(This is from GNU a2ps <https://savannah.gnu.org/projects/a2ps>'s
liba2ps/Makefile.am.)

When automake is run, it warns:

liba2ps/Makefile.am:63: warning: variable 'libnowarnings_a_LDFLAGS' is
defined but no program or
liba2ps/Makefile.am:63: library has 'libnowarnings_a' as canonical name
(possible typo)

I don't understand this, because libnowarnings.a is defined as the
canonical name of a library.

In src/Makfile.am, I have the following lines:

noinst_LIBRARIES = libparse.a
libparse_a_SOURCES = parsessh.y lexssh.l lexps.l sheets-map.l
libparse_a_CFLAGS = $(LIBGC_FLAGS)

and I get no warnings. I have no LTLIBRARIES in this Makefile.am.

If in the first Makefile.am I change the convenience library
"libnowarnings.a" to a libtool library "libnowarnings.la", and add it to
noinst_LTLIBRARIES, and rename the other variables accordingly, then again
I get no warnings.

-- 
https://rrt.sc3d.org


bug#61278: Automake warns about LDFLAGS for defined library

2023-02-04 Thread Reuben Thomas via Bug reports for Automake
On Sun, 5 Feb 2023 at 06:09, Nick Bowler  wrote:

>
> What Automake is trying to tell you is that LDFLAGS is meaningless
> on a static library.  This message could definitely be improved!
>

Of course, thanks! I was confused because  in another Makefile.am that had
only a static library I did not get this message, but I did not set LDFLAGS
there.

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-04-12 Thread Reuben Thomas via Bug reports for Automake
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:

$ make all
make  all-am
make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src'
  YACC parsessh.c
  CC   libparse_a-lexssh.o
/home/rrt/repo/a2ps/src/ylwrap1077905
lexssh.c:38:11: fatal error: parsessh.h: No such file or directory
   38 |  #include "parsessh.h"
  |   ^~~~
compilation terminated.
make[1]: *** [Makefile:1710: libparse_a-lexssh.o] Error 1
make[1]: *** Waiting for unfinished jobs
parsessh.output is unchanged
updating parsessh.h
make[1]: Leaving directory '/home/rrt/.local/var/repo/a2ps/src'
make: *** [Makefile:1514: all] Error 2

But parsessh.h is listed in BUILT_SOURCES, so it should be built before any
other target.

[1] git clone https://git.savannah.gnu.org/git/a2ps.git

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-04-12 Thread Reuben Thomas via Bug reports for Automake
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!

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-04-12 Thread Reuben Thomas via Bug reports for Automake
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.

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-12-06 Thread Reuben Thomas via Bug reports for Automake
On Sun, 3 Dec 2023 at 03:47, Mike Frysinger  wrote:

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

Thanks for the tip; on a belt-and-braces basis, it seems it can't hurt
anyway, so I've added the .h file back as well.

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-12-08 Thread Reuben Thomas via Bug reports for Automake
On Wed, 6 Dec 2023 at 23:59, Karl Berry  wrote:

> Any chance that one of you could write a patch for the manual to explain
> whatever needs to be explained (better)? --thanks, karl.
>

I'd happily do that if I could work out, or someone could explain, exactly
what's going on here.

The manual currently says: "You should never explicitly mention the
intermediate (C or C++) file in any ‘SOURCES’ variable; only list the
source file." Later, it talks about adding the header file to
"BUIILT_SOURCES". This seems at odds with what Mike said and I found
empirically.

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-12-09 Thread Reuben Thomas via Bug reports for Automake
On Sat, 9 Dec 2023 at 00:03, Karl Berry  wrote:

> The manual currently says: "You should never explicitly mention the
> intermediate (C or C++) file in any `SOURCES' variable; only list
> the source file."
>
> I don't know the code here, and this probably wasn't the question, but I
> think the manual's statement about "any `SOURCES' variables" was simply
> not meant to apply to BUILT_SOURCES (probably didn't think about it),
>

I did wonder that myself.

but rather to the "normal" something_SOURCES variables. So my gut
> reaction is to add "(except @code{BUILT_SOURCES}, see below)".
>
> Later, it talks about adding the header file to
> "BUIILT_SOURCES". This seems at odds with what Mike said and I found
> empirically.
>
> I suggest that we could just say to add both files, although if you want
> to try to understand what's actually going on, more power to you :).
>

In terms of solving the problem, that would seem the safer option.

If you're happy with that, I'll write a patch.

-- 
https://rrt.sc3d.org


bug#62791: BUILT_SOURCES not honoured in parallel build?

2023-12-09 Thread Reuben Thomas via Bug reports for Automake
On Sat, 9 Dec 2023 at 15:16, Reuben Thomas  wrote:

>
> If you're happy with that, I'll write a patch.
>

Patch attached.

-- 
https://rrt.sc3d.org
From 06f6765b7d10132d0dcefde1265b4d5f01df76b4 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Sat, 9 Dec 2023 15:20:44 +0200
Subject: [PATCH] doc: add advice to list Yacc/Lex generated sources in
 BUILT_SOURCES

This fixes #62791: it seems to be necessary to list the generated C source
file for a Yacc/Lex file, as well as the header file in BUILT_SOURCES.
---
 doc/automake.texi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index e53a44332..77292288d 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -6329,7 +6329,8 @@ extensions @file{.l}, @file{.ll}, @file{.l++}, @file{.lxx}, and
 @file{.lpp} are recognized.
 
 You should never explicitly mention the intermediate (C or C++) file
-in any @code{SOURCES} variable; only list the source file.
+in any @code{SOURCES} variable (except @code{BUILT_SOURCES}, see below);
+only list the source file.
 
 The intermediate files generated by @command{yacc} (or @command{lex})
 will be included in any distribution that is made.  That way the user
@@ -6359,11 +6360,11 @@ What Automake cannot guess, though, is where this header will be used:
 it is up to you to ensure the header gets built before it is first
 used.  Typically this is necessary in order for dependency tracking to
 work when the header is included by another file.  The common solution
-is listing the header file in @code{BUILT_SOURCES} (@pxref{Sources})
-as follows.
+is listing the header file, and the corresponding C file, in
+@code{BUILT_SOURCES} (@pxref{Sources}) as follows.
 
 @example
-BUILT_SOURCES = parser.h
+BUILT_SOURCES = parser.h parser.c
 AM_YFLAGS = -d
 bin_PROGRAMS = foo
 foo_SOURCES = @dots{} parser.y @dots{}
-- 
2.34.1



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

2024-04-15 Thread Eric Gallager via Bug reports for Automake
GCC developers have recently found a source of non-determinism in
automake; this is bad for reproducible builds:

-- Forwarded message -
From: Jakub Jelinek 
Date: Mon, Apr 15, 2024 at 8:43 AM
Subject: [PATCH] gotools: Workaround non-reproduceability of automake
To: Ian Lance Taylor , Mark Wielaard 
Cc: 


Hi!

The regen bot recently flagged a difference in gotools/Makefile.in.
Trying it locally, it seems pretty random
for i in `seq 20`; do
PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH automake; echo -n
`git diff Makefile.in | wc -l`" "; done; echo; for i in `seq 20`; do
PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH setarch x86_64 -R
automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo;
14 14 14 0 0 0 14 0 14 0 14 14 14 14 0 14 14 0 0 0
14 0 14 0 0 14 14 14 0 14 14 0 0 14 14 14 0 0 0 14
The 14 line git diff is
diff --git a/gotools/Makefile.in b/gotools/Makefile.in
index 36c2ec2abd3..f40883c39be 100644
--- a/gotools/Makefile.in
+++ b/gotools/Makefile.in
@@ -704,8 +704,8 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-@NATIVE_FALSE@install-exec-local:
 @NATIVE_FALSE@uninstall-local:
+@NATIVE_FALSE@install-exec-local:
 clean: clean-am

 clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
so whether it is
@NATIVE_FALSE@install-exec-local:
@NATIVE_FALSE@uninstall-local:
or
@NATIVE_FALSE@uninstall-local:
@NATIVE_FALSE@install-exec-local:
depends on some hash table traversal or what.

I'm not familiar with automake/m4 enough to debug that, so I'm
instead offering a workaround, with this patch the order is deterministic.

2024-04-15  Jakub Jelinek  

* Makefile.am (install-exec-local, uninstall-local): Add goals
on the else branch of if NATIVE to ensure reproducibility.
* Makefile.in: Regenerate.

--- gotools/Makefile.am.jj  2023-11-04 09:02:35.802995614 +0100
+++ gotools/Makefile.am 2024-04-15 14:30:03.647171636 +0200
@@ -366,5 +366,7 @@ else
 # only do this if such a compiler is available.  We also need to get
 # the right values for GOARCH and GOOS in the default build context in
 # the go/build package.  Figure this out later.
+install-exec-local:
+uninstall-local:

 endif
--- gotools/Makefile.in.jj  2023-11-03 17:08:46.000439645 +0100
+++ gotools/Makefile.in 2024-04-15 14:31:32.270040117 +0200
@@ -704,8 +704,6 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-@NATIVE_FALSE@install-exec-local:
-@NATIVE_FALSE@uninstall-local:
 clean: clean-am

 clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
@@ -1035,6 +1033,8 @@ mostlyclean-local:
 # only do this if such a compiler is available.  We also need to get
 # the right values for GOARCH and GOOS in the default build context in
 # the go/build package.  Figure this out later.
+@NATIVE_FALSE@install-exec-local:
+@NATIVE_FALSE@uninstall-local:

 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

Jakub





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

2024-04-17 Thread Eric Gallager via Bug reports for Automake
Makefile.am in question is from the gotools subdirectory of GCC:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gotools/Makefile.am;h=80b21847117fb1b685a677725826f4caba4e759e;hb=HEAD
Note that the original reporter, Jakub Jelinek, has said that this
might potentially be due to the use of an old version, so this might
not actually be a current bug after all:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649576.html

On Wed, Apr 17, 2024 at 11:56 AM Karl Berry  wrote:
>
> so whether it is
> @NATIVE_FALSE@install-exec-local:
> @NATIVE_FALSE@uninstall-local:
> or
> @NATIVE_FALSE@uninstall-local:
> @NATIVE_FALSE@install-exec-local:
> depends on some hash table traversal or what.
>
> Thanks for the report. Any chance of a Makefile.am that can reproduce
> the problem? I wonder if it's related to the @NATIVE_FALSE@ somehow.
>
> Looking at automake.in, it's not obvious to me where a list is failed to
> be sorted. Those -local targets aren't generated by automake itself, so
> far as I can see. --thanks, karl.
>





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

2024-04-24 Thread Reuben Thomas via Bug reports for Automake
I attach two patches. The first is a trivial documentation fix. The second
fixes a bug I ran into recently with Vala compilation.

I just needed to add some Vala source files to my program that are added to
the relevant _SOURCES variable conditionally:

if OS_WIN32
libenchant_la_SOURCES += api-windows.vala
else
libenchant_la_SOURCES += api-posix.vala
endif

(Motivation: the reason I have to add the files conditionally is two-fold:
first, api-windows.vala and api-posix.vala call APIs that are only
available on Windows and POSIX systems respectively. In itself, this does
not require conditional inclusion; I can use Vala preprocessor directives,
just as I would in C. But the Vala compiler generates C files, and I want
the user of my package not to need a Vala compiler. Therefore, the
generated C code must be independent of build-time configuration. Since the
Vala compiler does not generate C preprocessor directives, I have to do
conditional inclusion at build time some other way. So, I am doing it by
using automake conditionals.)

With current automake, something like the following Makefile line is
generated:

$(builddir)/libenchant_la_vala.stamp: api-windows.vala api-posix.vala…

With my patch, the following line is generated instead:

$(builddir)/libenchant_la_vala.stamp: $(libenchant_la_SOURCES)

Of course, $(libenchant_la_SOURCES) expands to the actual sources.

The patch is trivial, so hopefully it's obvious if there's a problem for
some reason! I hope I explained well enough what problem I'm trying to
solve.

-- 
https://rrt.sc3d.org
From 490777db71c2086cfbd3ec359fceca5fc853047d Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 24 Apr 2024 22:41:48 +0200
Subject: [PATCH 2/2] vala: do not build Vala sources excluded by automake
 conditionals
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* bin/automake.in: make the _vala.stamp file depend on the relevant _SOURCES
variable’s value, not the fully-expanded list of all possible sources. This
means that source files added conditionally to a _SOURCES variable will only
be added when the condition is true.
---
 bin/automake.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 112730269..95129c294 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5887,7 +5887,7 @@ sub lang_vala_finish_target
   my $stampfile = "\$(builddir)/${derived}_vala.stamp";
 
   $output_rules .=
-"\$(builddir)/${derived}_vala.stamp: @vala_sources\n".
+"\$(builddir)/${derived}_vala.stamp: \$(${derived}_SOURCES)\n".
 # Since the C files generated from the vala sources depend on the
 # ${derived}_vala.stamp file, we must ensure its timestamp is older than
 # those of the C files generated by the valac invocation below (this is
-- 
2.34.1

From 32ad6da2af34725cbb771e8f3824370cd15a0540 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 24 Apr 2024 22:41:12 +0200
Subject: [PATCH 1/2] doc: add missing close parenthesis in comment.

* bin/automake.in: add missing close parenthesis.
---
 bin/automake.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 1dc40a00b..112730269 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5809,7 +5809,7 @@ sub lang_vala_finish_target
   #
   # The -newer test here is checking "C file not older than Vala
   # file" (not "C file newer than Vala file"; see
-  # https://bugs.gnu.org/44772. The log message on the commit
+  # https://bugs.gnu.org/44772 ). The log message on the commit
   # misleadingly says "reversed".
   #
   $output_rules .= "$built_c_file: \$(builddir)/${derived}_vala.stamp\n"
-- 
2.34.1



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

2024-04-24 Thread Reuben Thomas via Bug reports for Automake
On Wed, 24 Apr 2024 at 22:57, Reuben Thomas  wrote:

>
> The patch is trivial, so hopefully it's obvious if there's a problem for
> some reason! I hope I explained well enough what problem I'm trying to
> solve.
>

Apologies, I should have run the tests before posting the patch. Indeed, I
have broken things. So, please consider the documentation patch, and I'll
take another look at the bug-fix (which in any case I have also realised
does not solve my problem; it is the wrong approach!).

-- 
https://rrt.sc3d.org


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

2024-04-24 Thread Reuben Thomas via Bug reports for Automake
On Wed, 24 Apr 2024 at 23:38, Reuben Thomas  wrote:

> Apologies, I should have run the tests before posting the patch. Indeed, I
> have broken things. So, please consider the documentation patch, and I'll
> take another look at the bug-fix (which in any case I have also realised
> does not solve my problem; it is the wrong approach!).
>

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

-- 
https://rrt.sc3d.org
From 93790078f509a4266da6bb436d1841feb7d0 Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Wed, 24 Apr 2024 22:41:48 +0200
Subject: [PATCH 2/2] vala: do not build Vala sources excluded by automake
 conditionals
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* bin/automake.in: make the _vala.stamp file depend on the relevant _SOURCES
variable’s value, not the fully-expanded list of all possible sources. This
means that source files added conditionally to a _SOURCES variable will only
be added when the condition is true.
---
 bin/automake.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/automake.in b/bin/automake.in
index 112730269..5c5afa0b2 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -5887,7 +5887,7 @@ sub lang_vala_finish_target
   my $stampfile = "\$(builddir)/${derived}_vala.stamp";
 
   $output_rules .=
-"\$(builddir)/${derived}_vala.stamp: @vala_sources\n".
+"\$(builddir)/${derived}_vala.stamp: \$(filter %.vala %.vapi,\$(${derived}_SOURCES))\n".
 # Since the C files generated from the vala sources depend on the
 # ${derived}_vala.stamp file, we must ensure its timestamp is older than
 # those of the C files generated by the valac invocation below (this is
-- 
2.34.1



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

2024-04-27 Thread Reuben Thomas via Bug reports for Automake
On Sat, 27 Apr 2024 at 00:53, Karl Berry  wrote:

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

No problem, I will do this when I can find a moment. Since I don't actually
need this fix after all, it may not be quick!

-- 
https://rrt.sc3d.org


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

2024-04-28 Thread Reuben Thomas via Bug reports for Automake
On Sat, 27 Apr 2024 at 20:36, Reuben Thomas  wrote:

> On Sat, 27 Apr 2024 at 00:53, Karl Berry  wrote:
>
>> Reuben, any chance you can whomp up a test for this patch?
>>
>
> No problem, I will do this when I can find a moment. Since I don't
> actually need this fix after all, it may not be quick!
>

I found a moment, but not a fix. In fact, a fix is not in general possible
(or at least, not without a considerable amount of messing around). The
problem is that the Vala compiler needs to be able to see all the symbols
in the program, so you have to give it all the source files at once, so you
can't give it source files that contain alternative (duplicate) definitions
of the same symbol.

Hence, having conditionally-added sources like this is not compatible with
shipping all C sources in the tarball, or to put it another way, with
making the Vala compiler optional. But I think this is a great feature of
Automake's Vala support! (Certainly, I believe it is unique.)

So if Automake had in future a mode where it shipped only Vala sources,
then in that mode it would make sense to conditionally-include Vala
sources, and that would work.

As a consolation, I attach another patch that fixes some English in
comments in one of the Vala tests.

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

-- 
https://rrt.sc3d.org
From 1224a4ef1d9a983cd45de42b466bda8d919446be Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Sun, 28 Apr 2024 20:42:20 +0200
Subject: [PATCH 2/3] vala: fix some English in test comments

---
 t/vala-vapi.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/vala-vapi.sh b/t/vala-vapi.sh
index dfdb0a8e5..998371019 100644
--- a/t/vala-vapi.sh
+++ b/t/vala-vapi.sh
@@ -14,7 +14,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
-# Test and that vapi files are correctly handled by Vala support.
+# Test that vapi files are correctly handled by Vala support.
 
 required='pkg-config valac cc GNUmake'
 . test-init.sh
@@ -42,7 +42,7 @@ public class Zardoz {
 }
 END
 
-# Use printf, not echo, to avoid '\n' being considered and escape
+# Use printf, not echo, to avoid '\n' being considered an escape
 # sequence and printed as a newline in 'foo.h'.
 printf '%s\n' '#define BARBAR "Zardoz!\n"' > foo.h
 
@@ -78,7 +78,7 @@ cross_compiling || $MAKE test1 || exit 1
 
 # Simple check on remake rules.
 $sleep
-# Use printf, not echo, to avoid '\n' being considered and escape
+# Use printf, not echo, to avoid '\n' being considered an escape
 # sequence and printed as a newline in 'foo.h'.
 printf '%s\n' '#define BAZBAZ "Quux!\n"' > foo.h
 sed 's/BARBAR/BAZBAZ/' zardoz.vala > t && mv -f t zardoz.vala || exit 99
-- 
2.34.1



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

2024-04-30 Thread Reuben Thomas via Bug reports for Automake
On Mon, 29 Apr 2024 at 23:29, Karl Berry  wrote:

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

Attached.

-- 
https://rrt.sc3d.org
From eead600ffcf3d2ad56f2da25ea8371dca40432ea Mon Sep 17 00:00:00 2001
From: Reuben Thomas 
Date: Tue, 30 Apr 2024 09:59:58 +0200
Subject: [PATCH] doc: update Vala documentation

* Update the URL for Vala.
* Drop the mention of a version requirement, as no current system will have a
too-old version of Vala.
* Note the restriction on conditional inclusion of source files in *_SOURCES.
---
 doc/automake.texi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/doc/automake.texi b/doc/automake.texi
index d30905e0f..e48079f44 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -7023,18 +7023,21 @@ the @code{_LDFLAGS} variable for the program.
 @cindex Vala Support
 @cindex Support for Vala
 
-Automake provides initial support for Vala
-(@uref{https://www.vala-project.org/}).
-This requires valac version 0.7.0 or later, and currently requires
-the user to use GNU @command{make}.
+Automake supports Vala (@uref{https://vala.dev/}).
+Vala support requires the user to use GNU @command{make}.
 
 @example
 foo_SOURCES = foo.vala bar.vala zardoz.c
 @end example
 
 Any @file{.vala} file listed in a @code{_SOURCES} variable will be
-compiled into C code by the Vala compiler. The generated @file{.c} files
-are distributed. The end user does not need to have a Vala compiler installed.
+compiled into C code by the Vala compiler.  The generated @file{.c}
+files are distributed. The end user does not need to have a Vala
+compiler installed.  Because all C files must be generated, and the Vala
+compiler compiles all the @file{.vala} files for a target at once, it is
+not possible to add files to a @code{_SOURCES} variable that cannot be
+compiled together; for example, alternative platform-specific
+definitions of the same methods.
 
 Automake ships with an Autoconf macro called @code{AM_PROG_VALAC}
 that will locate the Vala compiler and optionally check its version
-- 
2.34.1



bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0

2024-09-03 Thread Eric Gallager via Bug reports for Automake
On Wed, Aug 28, 2024 at 6:43 PM Karl Berry  wrote:
>
> Hi Eric,
>
> Subject: bug#72852: Testsuite summary for GNU Automake 1.17 on
>  x86_64-apple-darwin20.6.0
>
> Thanks for the report. It looks like Apple's compiler, or linker, or
> something, is leaving new files, in fact a whole new directory, behind.

Yeah, both llvm and gcc are set up on darwin so that their compiler
drivers will invoke dsymutil as part of the compilation process:
https://llvm.org/docs/CommandGuide/dsymutil.html
Search for COLLECT_RUN_DSYMUTIL in the GCC sources to see how it's invoked:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=11afe8e8c87cd525efbaab282b2c01d6a52e9d86

> I didn't check all the failures, but the ones I looked at ended up with
> errors like:
>
>   ERROR: files left in build directory after distclean:
>   ./foo.dSYM/Contents/Resources/DWARF/foo
>   ./foo.dSYM/Contents/Info.plist
>   make[1]: *** [distcleancheck] Error 1
>
> I know nothing about what's going on, but just looking at that, I'm
> guessing make clean should also rm -rf .dSYM.

Yeah, that sounds correct.

> (Bogdan, wdyt?)
> --thanks, karl.





bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

2024-09-10 Thread Eric Gallager via Bug reports for Automake
On Tue, Sep 10, 2024 at 6:46 PM Karl Berry  wrote:
>
> Hi Eric - I've just committed a change that I hope fixes the version
> number problem.  (See https://bugs.gnu.org/72157)
>
> However, looking at your list of failures, I see that some of them are
> still about *.dSYM, now relating to distclean. E.g.,
> t/yacc-bison-skeleton-cxx.sh shows:
>
>   ERROR: files left in build directory after distclean:
>   ./zardoz.dSYM/Contents/Resources/DWARF/zardoz
>   ./zardoz.dSYM/Contents/Info.plist
>
> I guess the removal list has to be updated in another place.
> If you have a chance to look into it, that would be great.
>

Well, my patch just updated the _AM_PROG_CC_C_O autoconf macro, so I
guess that .dSYM bundles still need to be added to the default list of
files that get cleaned? They get created alongside executables, so
whichever of the "clean" rules (mostlyclean, clean, distclean,
maintainer-clean, etc.) that executables get cleaned up during, any
.dSYM bundles whose names start the same should also get cleaned
during that same step... Kinda busy with political stuff at the
moment, but I'll take a look once I get a chance...

> Thanks,
> Karl





bug#72852: closed (Re: bug#72852: Testsuite summary for GNU Automake 1.17 on x86_64-apple-darwin20.6.0)

2024-09-11 Thread Eric Gallager via Bug reports for Automake
On Tue, Sep 10, 2024 at 10:59 PM Eric Gallager  wrote:
>
> On Tue, Sep 10, 2024 at 6:46 PM Karl Berry  wrote:
> >
> > Hi Eric - I've just committed a change that I hope fixes the version
> > number problem.  (See https://bugs.gnu.org/72157)
> >
> > However, looking at your list of failures, I see that some of them are
> > still about *.dSYM, now relating to distclean. E.g.,
> > t/yacc-bison-skeleton-cxx.sh shows:
> >
> >   ERROR: files left in build directory after distclean:
> >   ./zardoz.dSYM/Contents/Resources/DWARF/zardoz
> >   ./zardoz.dSYM/Contents/Info.plist
> >
> > I guess the removal list has to be updated in another place.
> > If you have a chance to look into it, that would be great.
> >
>
> Well, my patch just updated the _AM_PROG_CC_C_O autoconf macro, so I
> guess that .dSYM bundles still need to be added to the default list of
> files that get cleaned? They get created alongside executables, so
> whichever of the "clean" rules (mostlyclean, clean, distclean,
> maintainer-clean, etc.) that executables get cleaned up during, any
> .dSYM bundles whose names start the same should also get cleaned
> during that same step... Kinda busy with political stuff at the
> moment, but I'll take a look once I get a chance...
>

OK, I ran the testsuite after the latest commit, and the number of
failures is back down to 8 again... looking at where else to clean up
the .dSYM bundles, I guess in lib/am/progs.am would make sense? Under
the clean-%DIR%PROGRAMS: target... although, I guess first I need to
find out where/how the $(%DIR%_PROGRAMS) variable is set...

> > Thanks,
> > Karl





bug#74453: running make failed when perl is installed in the very long path

2024-11-21 Thread Changqing Li via Bug reports for Automake


On 11/21/24 12:56, Nick Bowler wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On 2024-11-20 21:56, Li, Changqing via Bug reports for Automake wrote:

The failure is caused by the long path of the perl in aclocal.in,  the
shebang  is cutted.  Could we change it like following diff?
[...]
-#!@PERL@
+#!/usr/bin/env perl

Hardcoding program names like this isn't really going to work well as a
general solution.

I was going to suggest you could just configure for your system with:

   ./configure PERL='/usr/bin/env perl'

and it will substitute that into the scripts for you, but the configure
script in Automake 1.17 exits with a fatal error if it determines that
$PERL contains spaces.  We should probably make this non fatal since the
check is clearly too broad.  You can patch configure to not exit:

--- configure~
+++ configure
@@ -3514,7 +3514,7 @@ case $PERL in
 as_fn_error $? "perl not found" "$LINENO" 5
 ;;
   *' '* | *''*)
-  as_fn_error $? "The path to your Perl contains spaces or tabs.
+:  as_fn_error $? "The path to your Perl contains spaces or tabs.
  This would cause build failures later or unusable programs.
  Please use a path without spaces and try again." "$LINENO" 5
;;

and then it will let you set PERL='/usr/bin/env perl' and it will work.


@Nick,  Thanks for your help.

Regards

Changqing



Hope that helps,
   Nick

bug#74453: running make failed when perl is installed in the very long path

2024-11-26 Thread Bruno Haible via Bug reports for Automake
Collin Funk cited me:
> As Bruno Haible said in a Gnulib thread [1]:
> 
> > "#!/usr/bin/env perl" does not work on GuixSD (where the only program
> > that has a hardcoded file name is /bin/sh; there is no /usr and no
> > /bin/env on this distro).
> 
> So I don't think it would work in this case.
> 
> Collin
> 
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-06/msg00022.html

That was in 2019. Meanwhile, in GuixSD 1.4, both /bin/sh and /usr/bin/env
exist. So, writing

  #!/usr/bin/env perl

is now again the portable way to start a perl script.

Bruno








bug#74453: running make failed when perl is installed in the very long path

2024-11-26 Thread Bruno Haible via Bug reports for Automake
Nick Bowler wrote:
> The Linux program loader expects to find a newline in the first 128
> bytes of the file (increased to 256 in recent versions), otherwise
> you will get an ENOEXEC error from execve.

My testing indicates:

The first line which specifies the interpreter and interpreter args is limited 
in length:
  - max. 253 characters on Linux
  - max. 513 characters on macOS
  - max. 1025 characters on NetBSD
  - max. 125 characters on OpenBSD
  - max. 1022 characters on AIX
  - max. 1021 characters on Solaris
On Linux and AIX, characters exceeding this limit are simply cut off by the 
system.
On macOS, NetBSD, OpenBSD, and Solaris, the script is not executed at all if 
this line is too long.

Bruno








bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-03 Thread Bruno Haible via Bug reports for Automake
Kirill Makurin wrote:
> I applied patches and they work for Msys2.
> 
> I also tested it with (what I assume is) "Msys-based MinGW" 
> (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports 
> `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly set `file_conv` to `mingw` in compile just for testing with this 
> MinGW and there are no issues with double conversion.

Thanks for testing.

In the download area of https://osdn.net/projects/mingw/, I cannot see an
"Msys-based MinGW". Rather, the page says
  "This is the official download site for the latest packages originating
   from the MinGW.OSDN Project, (formerly the MinGW.org Project; however,
   that domain is no longer associated with this project)."

Maybe the mix between the original MinGW and MSYS occurred on your machine?

Anyway, here's an update of the patch series, that should make things work
also in this situation (regardless how it originated).

I wouldn't want to test for the presence of 'cygpath' _without_ also testing
$MSYSTEM, because that could malfunction for people who access the original
MinGW binaries through a Cygwin environment (which is another mix-up that
people might do).

Bruno

>From fa6a98993ea95ce576c79e597cda5e166f36ba5e Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 3 Feb 2025 06:02:07 +0100
Subject: [PATCH 1/3] compile: Simplify.

* lib/compile (func_file_conv): Remove unnecessary code, added on 2019-11-11.
* lib/ar-lib (func_file_conv): Likewise.
---
 lib/ar-lib  | 4 ++--
 lib/compile | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/ar-lib b/lib/ar-lib
index 7d62dea99..85761fbf1 100755
--- a/lib/ar-lib
+++ b/lib/ar-lib
@@ -2,7 +2,7 @@
 # Wrapper for Microsoft lib.exe
 
 me=ar-lib
-scriptversion=2024-06-19.01; # UTC
+scriptversion=2025-02-03.05; # UTC
 
 # Copyright (C) 2010-2025 Free Software Foundation, Inc.
 # Written by Peter Rosin .
@@ -65,7 +65,7 @@ func_file_conv ()
 	mingw)
 	  file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
 	  ;;
-	cygwin | msys)
+	cygwin)
 	  file=`cygpath -m "$file" || echo "$file"`
 	  ;;
 	wine)
diff --git a/lib/compile b/lib/compile
index 14aec5621..e80b054a0 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand '-c -o'.
 
-scriptversion=2024-12-03.03; # UTC
+scriptversion=2025-02-03.05; # UTC
 
 # Copyright (C) 1999-2025 Free Software Foundation, Inc.
 # Written by Tom Tromey .
@@ -67,7 +67,7 @@ func_file_conv ()
 	mingw/*)
 	  file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
 	  ;;
-	cygwin/* | msys/*)
+	cygwin/*)
 	  file=`cygpath -m "$file" || echo "$file"`
 	  ;;
 	wine/*)
-- 
2.43.0

>From afa958e0d4382f5fc6e1be236ae4718b83ec42b0 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 3 Feb 2025 06:10:09 +0100
Subject: [PATCH 2/3] compile: Distinguish various MinGW, MSYS, MSYS2
 environments correctly.

Reported by Kirill Makurin  in
.

* lib/compile (func_file_conv): Use not only "uname -s", but also $MSYSTEM and
the presence of cygpath, in order to distinguish the original MinGW and MSYS2.
* lib/ar-lib (func_file_conv): Likewise.
---
 lib/ar-lib  | 15 +--
 lib/compile | 23 ++-
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/lib/ar-lib b/lib/ar-lib
index 85761fbf1..f85f879d8 100755
--- a/lib/ar-lib
+++ b/lib/ar-lib
@@ -51,9 +51,20 @@ func_file_conv ()
 	# lazily determine how to convert abs files
 	case `uname -s` in
 	  MINGW*)
-	file_conv=mingw
+	if test -n "$MSYSTEM" && (cygpath --version) >/dev/null 2>&1; then
+	  # MSYS2 environment.
+	  file_conv=cygwin
+	else
+	  # Original MinGW environment.
+	  file_conv=mingw
+	fi
 	;;
-	  CYGWIN* | MSYS*)
+	  MSYS*)
+	# Old MSYS environment, or MSYS2 with 32-bit MSYS2 shell.
+	file_conv=cygwin
+	;;
+	  CYGWIN*)
+	# Cygwin environment.
 	file_conv=cygwin
 	;;
 	  *)
diff --git a/lib/compile b/lib/compile
index e80b054a0..fc738d3d9 100755
--- a/lib/compile
+++ b/lib/compile
@@ -37,11 +37,11 @@ IFS=" ""	$nl"
 
 file_conv=
 
-# func_file_conv build_file lazy
+# func_file_conv build_file unneeded_conversions
 # Convert a $build file to $host form and store it in $file
 # Currently only supports Windows hosts. If the determined conversion
-# type is listed in (the comma separated) LAZY, no conversion will
-# take place.
+# type is listed in (the comma separated) UNNEEDED_CONVERSIONS, no
+# conversion will take place.
 func_file_conv ()
 {
   file=$1
@@ -51,9 +51,20 @@ func_file_conv ()
 	# lazily determine how to convert abs files
 	case `uname -s` in
 	  MINGW*)
-	file_conv=mingw
+	if test -n "$MSYSTEM" && (cygpath --version) >/dev/null 2>&1; then
+	  # MSYS2 environment.
+	  file_conv=cygwin
+	else
+	  # Original MinGW environment.
+	  file_conv=mingw
+	fi
 	;;
-	  CYGWIN* | 

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-03 Thread Bruno Haible via Bug reports for Automake
Kirill Makurin wrote:
> The installer from https://osdn.net/projects/mingw/ is the same as
> found in https://sourceforge.net/projects/mingw/ (except for possible
> difference in versions) and the Wikipedia article points to the former
> website (mingw.org website is no longer alive). This installer provides
> both `mingw-*` (gcc, binutils) and `msys-*` (bash, autotools, etc.)
> packages. I am using its `msys.bat` to start the shell.

Ok, I see. So, the web site of the original MinGW at some point started
to distribute a mix between MinGW and MSYS. And in this case
  `uname -s` is MINGW*,
  $MSYSTEM is non-empty,
  cygpath is not present.

The proposed code will then branch into this statement:

  # Original MinGW environment.
  file_conv=mingw

> I tested updated patches and they work for both Msys2 and *MinGW*. For 
> completeness, I also tried using it from Cygwin and it works as expected.

Thank you. Karl, the three patches from the preceding mail are ready
to commit.

Bruno








bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-02 Thread Bruno Haible via Bug reports for Automake
Kirill Makurin wrote:
> I was going to just say that this patch is good and go ahead with it, but I 
> decided to check it and turns out it fixes this issue only partially, but the 
> patch itself is good.
> 
> Msys2 has multiple environments (see 
> https://www.msys2.org/docs/environments/) and this patch works only for 
> `MSYS`. For all other environments `uname` will report a string starting with 
> `MINGW64` and `compile` will set `file_conv` variable to `mingw`. This, 
> unfortunately, overlaps with mingw32 which does not have `cygpath`.
> 
> For `mingw` the filename is converted in `compile` as follows:
> 
> ```
> mingw/*)
>   file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
> ```
> 
> The resulting converted filename has forward slashes as with `cygpath -m` and 
> suffers from the same double conversion issue.
> 
> In theory we could prepend `cygpath` invocation in this branch like this:
> 
> ```
> mingw/*)
>   file=`cygpath -w  "$file" 2>/dev/null || cmd //C echo "$file " | sed -e 
> 's/"\(.*\) " *$/\1/'`
> ```
> 
> However, compilation is still going to fail if there is no `cygpath` (also 
> ,`cygpath` is not installed with Msys2 by default).
> 
> I think a better solution may be to add additional sed invocation in the pipe 
> to convert forward slashes to backslashes.
> 
> I also was wondering if passing `mingw` as the second argument into 
> `func_file_conv ` in this branch could help, but unfortunately `/filename` in 
> resulting `-Tp/filename` is not converted by Msys2.
> 
> ```
> *.cc | *.CC | *.cxx | *.CXX | *.[cC]++)
>     func_file_conv "$1"
> ```
> 
> I hope I didn't cause too much confusion about `MSYS2_ARG_CONV_EXCL`, I was a 
> bit in a hurry and probably didn't make it clear that I meant setting 
> `MSYS2_ARG_CONV_EXCL` more like an external user-side workaround (e.g. I was 
> setting it in my build script).
> 
> - Kirill Makurin

Thanks for testing.

> For all other environments `uname` will report a string starting with 
> `MINGW64`
> and `compile` will set `file_conv` variable to `mingw`.

OK, so what you saying is the detection / distinction of environments
is not working. Which is quite plausible, since the original code was
written in 2010 (when MSYS2 did not exist) and Paul's patch from 2019-11-11
was apparently not well tested (Paul is not using Windows environments).

So, let's fix this environment distinction. This is better than applying
workarounds that will affect behaviour on the original MinGW.

Here are 3 proposed patches:

0001) This is a cleanup of Paul's patch from 2019-11-11. Since $file_conv
  can only have one of the three values 'mingw', 'cygwin', 'wine',
  it is pointless to test whether this value is 'msys'.

0002) This patch extends the distinction of environments. Since I don't
  have first-hand info about these environments, I asked the prior
  knowledge summarization engine. Results are attached. I trust these
  answers, because MinGW + MSYS is a topic that is widely discussed
  on the web.

0003) This patch is the same as already proposed: use backslashed filenames
  instead of forward-slashes ones (that MSYS2 would interpret a second
  time).

Kirill: Testing of this patch series in your environment (MSYS2 + MSVC)
is welcome.

Bruno
>From fa6a98993ea95ce576c79e597cda5e166f36ba5e Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 3 Feb 2025 06:02:07 +0100
Subject: [PATCH 1/3] compile: Simplify.

* lib/compile (func_file_conv): Remove unnecessary code, added on 2019-11-11.
* lib/ar-lib (func_file_conv): Likewise.
---
 lib/ar-lib  | 4 ++--
 lib/compile | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/ar-lib b/lib/ar-lib
index 7d62dea99..85761fbf1 100755
--- a/lib/ar-lib
+++ b/lib/ar-lib
@@ -2,7 +2,7 @@
 # Wrapper for Microsoft lib.exe
 
 me=ar-lib
-scriptversion=2024-06-19.01; # UTC
+scriptversion=2025-02-03.05; # UTC
 
 # Copyright (C) 2010-2025 Free Software Foundation, Inc.
 # Written by Peter Rosin .
@@ -65,7 +65,7 @@ func_file_conv ()
 	mingw)
 	  file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
 	  ;;
-	cygwin | msys)
+	cygwin)
 	  file=`cygpath -m "$file" || echo "$file"`
 	  ;;
 	wine)
diff --git a/lib/compile b/lib/compile
index 14aec5621..e80b054a0 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand '-c -o'.
 
-scriptversion=2024-12-03.03; # UTC
+scriptversion=2025-02-03.05; # UTC
 
 # Copyright (C) 1999-2025 Free Software Foundation, Inc.
 # Written by Tom Tromey .
@@ -67,7 +67,7 @@ func_file_conv ()
 	mingw/*)
 	  file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
 	  ;;
-	cygwin/* | msys/*)
+	cygwin/*)
 	  file=`cygpath -m "$file" || echo "$file"`
 	  ;;
 	wine/*)
-- 
2.43.0

>From 294cedfe2548ef8ccdf5162e2074eb1edd0cb094 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Mon, 3 Feb 2025 06:10:09 +0100
Subject: [PATCH 2/3] compile: Distinguish various MinGW, MSYS, M

bug#75939: setting $MSYS2_ARG_CONV_EXCL in compile script?

2025-02-02 Thread Bruno Haible via Bug reports for Automake
Karl Berry wrote:
> Kirill (cc'd) proposed setting the MSYS2_ARG_CONV_EXCL envvar in the
> compile script which comes from Automake, to avoid a double-conversion.
> See his report in the first msg here, and the final suggestion in the last:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75939
> 
> I don't know anything about this. I've never done any programming under
> Windows, or msys, cygwin, wine, or any other Unix emulator under Windows.
> 
> So I wanted to ask for advice before tinkering with something as basic
> as the compile script in this way. Especially since it currently does
> not set any environment variables.
> 
> So ... I'm hoping for feedback like "yeah sure", or "no, we should do
> xyz instead", or "the problem is actually abc", or something. Since no
> feedback was forthcoming on the automake list, I'm trying here.
> 
> And if we do apply it, then where? In this branch?
>   cygwin/* | msys/*)
> file=`cygpath -m "$file" || echo "$file"`
> 
> But I fear this will cause trouble on cygwin. But if we separate the
> branches, then it seems like other trouble could ensue. Setting it
> unconditionally in all cases seems unnecessarily global to me, though
> maybe that is the simplest.

Table of contents:
* Cygwin vs. MSYS2
* Nature of the MSYS2 problem
* General recommendation
* Specific proposal

* == Cygwin vs. MSYS2

MSYS2_ARG_CONV_EXCL is documented in
https://www.msys2.org/docs/filesystem-paths/#process-arguments
Quote:
  "When calling native executables from the context of [MSYS] then all the
   arguments that look like Unix paths will get auto converted to Windows."

Cygwin and MSYS2 both are development environments for native Windows
programs on Windows. Cygwin passes argv[] from the caller to the callee
unmodified; MSYS2 modifies it, at every program invocation, based on
heuristics.

On Cygwin, therefore, it is the programmer's responsibility to use
'cygpath -w' at the appropriate places. Fortunately, there is a Gnulib
macro, build-to-host.m4, that makes this easy.

* == Nature of the MSYS2 problem

The MSYS2 problem is that it's a horrible hack that is based on a
heuristic: all arguments that "look like Unix paths" are modified.

The user can set MSYS2_ARG_CONV_EXCL to avoid this from happening
in 1, 2, 3, or 10 places. But it will never be 100% correct.

* == General recommendation

My general advice is:
  1) Recommend Cygwin, not MSYS2. Like I do in
 
<https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob_plain;f=INSTALL.windows;hb=HEAD>
  2) Reduce the effort for GNU package upstream maintainers, by
 requesting a reasonably complete patch, not a piecemeal patch here
 and a piecemeal patch there.

* == Specific proposal

As for every bug report, the first action is to analyze the failure.
Here, the relevant lines of code in the 'compile' script are:

cygwin/* | msys/*)
  file=`cygpath -m "$file" || echo "$file"`

This is in function func_file_conv, which is used to produce arguments
for invocation of 'cl' (which is a native Windows program).

As documented in <https://cygwin.com/cygwin-ug-net/cygpath.html>,
"cygpath -m" produces file names like C:/Users/foobar/filename .
Some native Windows programs accept this syntax, some don't.
Therefore it is generally better to use "cygpath -w", which
produces file names like C:\Users\foobar\filename .
The *only* situation I've ever seen where "cygpath -m" is required
is when the callee is a shell script (with 'echo') that invokes
a Java program. (Example: IBM Application Server.)
Since the compiler called by 'compile' never is of this type, it is
better to use "cygpath -w".

Find attached a proposed patch. Tested on Cygwin with MSVC. Will work on
MSYS2 with MSVC as well.

Bruno
>From c0f453d1d2a52d21f24da17415de8ecbfbd19a3d Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 2 Feb 2025 15:40:20 +0100
Subject: [PATCH] compile: Improve support for C++ compilations on MSYS2.

Reported by Kirill Makurin  in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75939>.

* lib/compile (func_file_conv): Use 'cygpath -w', not 'cygpath -m'.
---
 lib/compile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/compile b/lib/compile
index 14aec5621..6f0e105a0 100755
--- a/lib/compile
+++ b/lib/compile
@@ -1,7 +1,7 @@
 #! /bin/sh
 # Wrapper for compilers which do not understand '-c -o'.
 
-scriptversion=2024-12-03.03; # UTC
+scriptversion=2025-02-02.14; # UTC
 
 # Copyright (C) 1999-2025 Free Software Foundation, Inc.
 # Written by Tom Tromey .
@@ -68,7 +68,7 @@ func_file_conv ()
 	  file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
 	  ;;
 	cygwin/* | msys/*)
-	  file=`cygpath -m "$file" || echo "$file"`
+	  file=`cygpath -w "$file" || echo "$file"`
 	  ;;
 	wine/*)
 	  file=`winepath -w "$file" || echo "$file"`
-- 
2.43.0



  1   2   >