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

echo "$PERL" | grep '[ \t]' I don't think there's any portable way to use \t to insert a tab in a shell string, besides literally. There's something like tab=`printf '\t'` .. "$tab" ... but I don't see a need to go that far here. I just used a literal tab char. also, can we really

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

very extensive "Portable Shell Programming" chapter: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Portable-Shell.html I know. The Autoconf manual already describes this issue in detail. The point of the brief mention in the Automake manual is because

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

However it looks like there is no tag defined for Objective C[1] (presumably it would be --tag=OBJC). Adding this option does appear to make things "work" in the sense that libtool just complains about the unknown tag but then proceeds to actually do stuff, rather than exiting

bug#67498:

Re: rhel8 test failure confirmation?

On Sat, Dec 2, 2023, at 6:58 AM, Mike Frysinger wrote: > On 06 Apr 2023 21:29, Jacob Bachmeyer wrote: >> Karl Berry wrote: >> > jb> a more thorough test would locate the autom4te script and grep it >> > for the perllibdir that was substituted when autoconf was >> > configured. >> > >>

Re: rhel8 test failure confirmation?

On 06 Apr 2023 21:29, Jacob Bachmeyer wrote: > Karl Berry wrote: > > jb> a more thorough test would locate the autom4te script and grep it > > for the perllibdir that was substituted when autoconf was > > configured. > > > > I guess that would work. > > Challenge accepted. Here's a

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

On 27 May 2023 19:12, Karl Berry wrote: > I (finally) installed this patch to quit early if the perl path has > spaces. Thanks. > > As for MKDIR_P and INSTALL, I guess it is somewhere in the > prerequisite/autoconf stuff. I suppose it would be rare that they would > be found in a path with spaces

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

On 18 Nov 2023 19:27, Karl Berry wrote: > Hi Michael, > > > Date: Sun, 16 Oct 2016 18:35:53 +0200 > From: Michael Stapelberg > To: automake-patches@gnu.org > Subject: [PATCH] texinfo: add pointer about combining tests > >

Re: Getting long SOURCES lines with subdirs shorter

On 01 Dec 2023 17:39, Nick Bowler wrote: > On 2023-12-01 15:37, Jan Engelhardt wrote: > > On Friday 2023-12-01 21:13, Mike Frysinger wrote: > >> On 17 Jul 2023 16:51, Karl Berry wrote: > >>> Hi Jan, > >>> > >>> Current automake likely won't have anything in store already, > >>> > >>> Not that

Re: Getting long SOURCES lines with subdirs shorter

On 01 Dec 2023 21:37, Jan Engelhardt wrote: > On Friday 2023-12-01 21:13, Mike Frysinger wrote: > >On 17 Jul 2023 16:51, Karl Berry wrote: > >> Hi Jan, > >> > >> Current automake likely won't have anything in store already, > >> > >> Not that I know of. > >> > >> a_SOURCES = $(addprefix

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

On 01 Dec 2023 16:10, Karl Berry wrote: > without realizing it's basically silently ignored. if we don't want > to support dnl, we should prob be chatty about it at some log level. > > The "Serials" node in the manual only mentions "#". I guess I don't see > a need to go out of our way

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

without realizing it's basically silently ignored. if we don't want to support dnl, we should prob be chatty about it at some log level. The "Serials" node in the manual only mentions "#". I guess I don't see a need to go out of our way to do anything else, given that this was the only

Re: Getting long SOURCES lines with subdirs shorter

On 2023-12-01 15:37, Jan Engelhardt wrote: > On Friday 2023-12-01 21:13, Mike Frysinger wrote: >> On 17 Jul 2023 16:51, Karl Berry wrote: >>> Hi Jan, >>> >>> Current automake likely won't have anything in store already, >>> >>> Not that I know of. >>> >>> a_SOURCES = $(addprefix

Re: Getting long SOURCES lines with subdirs shorter

On 17 Jul 2023 16:51, Karl Berry wrote: > Hi Jan, > > Current automake likely won't have anything in store already, > > Not that I know of. > > a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c) > > I've often wanted this myself. I'd certainly welcome a patch for it. > > Please

Re: Getting long SOURCES lines with subdirs shorter

On Friday 2023-12-01 21:13, Mike Frysinger wrote: >On 17 Jul 2023 16:51, Karl Berry wrote: >> Hi Jan, >> >> Current automake likely won't have anything in store already, >> >> Not that I know of. >> >> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c) >> >> I've often wanted

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

On 28 Nov 2023 16:27, Nick Bowler wrote: > On 2023-11-28 16:06, Karl Berry wrote: > > Hi Ross - you sent a change to automake-patches back in February 2017. > > Sorry for the absurdly delayed reply. > > > > > > https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html > > >

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

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get

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

Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get fixed.) At least, I have no idea what to

bug#64756: some frequent test failures

Hi Bruno, This is with Automake 1.16.5 and Autoconf 2.71 on an ext4 file system. [...] When I add an 'rm -rf autom4te.cache' command before 'automake -a -c', the failures disappear. FWIW, in the Automake development sources, there is now a test to see if autom4te is the new

bug#64756: some frequent test failures

Karl Berry wrote: > The various test-suite.log files show different test failures each > > Yes. Painful. I believe this is due to a timing problem with autom4te, > exposed by Automake using fractional second sleeps according to what the > filesystem supports. It is fixed in the autoconf

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

On 2023-11-28 16:06, Karl Berry wrote: > Hi Ross - you sent a change to automake-patches back in February 2017. > Sorry for the absurdly delayed reply. > > https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html > > Instead of only accepting comment lines that start

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

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

Hi Ross - you sent a change to automake-patches back in February 2017. Sorry for the absurdly delayed reply. https://lists.gnu.org/archive/html/automake-patches/2017-02/msg1.html Instead of only accepting comment lines that start with # for serial lines, also accept dnl. ...

bug#67477: Automake warns that $(?D) is a non-POSIX variable name

Naturally, now that I've reported this bug after I couldn't find it being already reported, I search again and find that it was already reported a long time ago: .

bug#67477: Automake warns that $(?D) is a non-POSIX variable name

Hi Quinn, > Automake seems to be aware of $(@D) and $(@F), but not the others. Thanks for the report. This was fixed not long ago, and will be in the next release. The prior report, for the record: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9587 All the best, Karl

[bug#67498] Fixes for Windows

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

[bug#67435] Fixes for Windows

On Fri, Nov 24, 2023 at 10:31:45AM -0700, Karl Berry wrote: > Hi Olly - back on your message from January 2018: > > https://lists.gnu.org/archive/html/automake-patches/2018-01/msg7.html > > I found I needed the two attached patches to build Xapian > (https://xapian.org) on

bug#67477: Automake warns that $(?D) is a non-POSIX variable name

POSIX Make allows the syntax $(@D) and $(@F) to be used to retrieve the directory and filename parts of the $@ internal macro. It also allows this syntax for the other four internal macros ($%, $?, $<, and $*). Automake seems to be aware of $(@D) and $(@F), but not the others. Here is an

bug#67268:

bug#67282:

[bug#67435] Fixes for Windows

Hi Olly - back on your message from January 2018: https://lists.gnu.org/archive/html/automake-patches/2018-01/msg7.html I found I needed the two attached patches to build Xapian (https://xapian.org) on Windows. The first patch was already applied some time ago. The second

[bug#67414] [PATCH] missing: add autoreconf, autogen and perl as supported programs

Hi Alex - back in July 2015, you sent an Automake patch to add support for autoreconf, etc., to the missing script: https://lists.gnu.org/archive/html/automake-patches/2015-08/msg0.html In the better late than never department, I've finally applied that patch, modulo a few unimportant

bug#20082: new warning from ar on rawhide systems

> And the patch against Automake attached now, sorry for the delay. https://lists.gnu.org/archive/html/automake-patches/2016-03/msg0.html In the better-late-than-never department: after eight years, I've finally applied this patch to make Automake's default ARFLAGS be cru instead of

[bug#67282] [PATCH] TAP driver: fix typos

Hi Jakub, Date: Tue, 15 Mar 2016 19:42:51 +0100 From: Jakub Wilk To: automake-patches@gnu.org Subject: [PATCH] TAP driver: fix typos https://lists.gnu.org/archive/html/automake-patches/2016-03/msg1.html Seven years late(r), but I did finally merge your typo fixes in

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

Hi Michael, Date: Sun, 16 Oct 2016 18:35:53 +0200 From: Michael Stapelberg To: automake-patches@gnu.org Subject: [PATCH] texinfo: add pointer about combining tests https://lists.gnu.org/archive/html/automake-patches/2016-10/msg2.html Seven years late(r), but I did

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

diff --git a/m4/sanity.m4 b/m4/sanity.m4 ... -if ! test -e conftest.file || grep 'slept: no' conftest.file >/dev/null 2>&1; then +AS_IF([test -e conftest.file || grep 'slept: no' conftest.file >/dev/null 2>&1],, [dnl Finally installed this change. (And closing.) Thanks Mike. -k

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

Subject: [bug#59991] [PATCH v2 0/3] Port tests to modern C I believe this "header patch" 59991 can be closed (so doing), since 59992, 59993, and 60962 have been merged. The related flex patch 59994 has also been merged. Let me know if anything along these lines is outstanding. --thanks,

bug#66352: parallel make yie lds "find: ���./conf*.dir��� : No such file or directory" errors

Thanks Vincent. Closing.

bug#66352: parallel make yields "find: ���./conf*.dir���: No such file or directory" errors

On 2023-11-03 10:28:38 -0600, Karl Berry wrote: > When I want to build Automake (current Git version) with > a parallel make ("make -j12"): > > I surmise this one was caused by the same random timing failures as your > other reports, 66353 and 66354. > > A couple days ago we finally

bug#66352: parallel make yields "find: ‘./conf*.dir’: No such file or directory" errors

When I want to build Automake (current Git version) with a parallel make ("make -j12"): I surmise this one was caused by the same random timing failures as your other reports, 66353 and 66354. A couple days ago we finally installed a patch (thanks Bogdan and Jacob) so that development

bug#32737: generated LDFLAGS order incorrect

bug#64756: some frequent test failures

Just to close this out: Bogdan worked up a patch to avoid the fractional-second timestamps unless the new (current autoconf development) autom4te is in used. Here is the basic change: https://git.savannah.gnu.org/cgit/automake.git/commit/?id=b6fa73115d094c8d0da1d6759b6e7c7fca1f8a07 (also appended

bug#65600: [bug#65730] [PATCH v2] m4: Update invocation of AC_PROG_LEX

* m4/lex.m4: pass the required argument to AC_PROG_LEX Łukasz, I finally committed your patch for this. Bogdan, I also committed your test. Thanks much. Closing these out (#65730, #65600). --karl

Re: armflang: error: unknown argument: '-soname'

> On 22 Oct 2023, at 22:28, Karl Berry wrote: > >While libtool has a new maintainer (Alex Ameen), essentially nothing >happens, which is quite unfortunate... > > 1) libtool 2.4.7 was released in March 2022 correct. However https://www.gnu.org/software/libtool/ still says: Latest

Re: armflang: error: unknown argument: '-soname'

> While libtool has a new maintainer (Alex Ameen), essentially > nothing happens, which is quite unfortunate... > > 1) libtool 2.4.7 was released in March 2022 (I don't know if Alex did >it), He did. > 2) When a package appears to be unmaintained, the first thing to do >[...]

bug#66679: automake: error: undefined condition 'TRUE' for 'info_TEXINFOS'

On Sun, Oct 22, 2023 at 5:28 PM Karl Berry wrote: > > automake: Please contact . > at /opt/local/share/automake-1.16/Automake/Channels.pm line 655. > Automake::Channels::msg("automake", "", "undefined condition > > Thanks for the report. I (or someone else ... Bogdan?) will look

bug#66679: automake: error: undefined condition 'TRUE' for 'info_TEXINFOS'

automake: Please contact . at /opt/local/share/automake-1.16/Automake/Channels.pm line 655. Automake::Channels::msg("automake", "", "undefined condition Thanks for the report. I (or someone else ... Bogdan?) will look into it as soon as we have a chance. Looking at the

Re: armflang: error: unknown argument: '-soname'

While libtool has a new maintainer (Alex Ameen), essentially nothing happens, which is quite unfortunate... 1) libtool 2.4.7 was released in March 2022 (I don't know if Alex did it), which isn't so terribly long ago. Sure, maintainers should at least confirm bug reports and patches, even

Re: armflang: error: unknown argument: '-soname'

Great! Thanks! On Sun, 2023-10-22 at 15:02 +, Shterenlikht, Anton wrote: > I confirm that the patch still works against > today's git version: > > $ libtool --version > libtool (GNU libtool) 2.4.7.4-1ec8f > > I just added "flang*" in addition to "armflang*": > >

Re: armflang: error: unknown argument: '-soname'

I confirm that the patch still works against today's git version: $ libtool --version libtool (GNU libtool) 2.4.7.4-1ec8f I just added "flang*" in addition to "armflang*": https://savannah.gnu.org/support/index.php?110947 I'm also asking in libt...@gnu.org why 2.4.6 is still the latest stable

Re: armflang: error: unknown argument: '-soname'

> here is a patch for libtool that Francois Coppens and I submitted to > libtool in February. I think we did something went wrong in the PR > process because it has still not been included... [...] While libtool has a new maintainer (Alex Ameen), essentially nothing happens, which is quite

Re: armflang: error: unknown argument: '-soname'

Dear Anton, here is a patch for libtool that Francois Coppens and I submitted to libtool in February. I think we did something went wrong in the PR process because it has still not been included... Maybe you can submit it again to the libtool team, it is not a big change and it is quite important

bug#66679: automake: error: undefined condition 'TRUE' for 'info_TEXINFOS'

In my attached `Makefile.am`, I have been trying to modify it so that it only rebuilds the documentation when explicitly asked to. Otherwise, the distributed copy should just get used instead. However, my modifications have led to the following error: doc/Makefile.am:23: warning: user target

Re: armflang: error: unknown argument: '-soname'

Karl, thank you I submitted a bug report with a reproducer: https://savannah.gnu.org/support/index.php?110947 Anton > On 21 Oct 2023, at 22:48, Karl Berry wrote: > > Hi Anton - thanks for the report. > >https://github.com/HDFGroup/hdf5/issues/366 >with the solution that "-Wl," must

Re: armflang: error: unknown argument: '-soname'

Hi Anton - thanks for the report. https://github.com/HDFGroup/hdf5/issues/366 with the solution that "-Wl," must be prepended somehow to "-soname". Why do you think this is not a libtool issue? Isn't it libtool's job to figure out the arguments that need to be passed? The fact that the

armflang: error: unknown argument: '-soname'

[also posted in libt...@gnu.org] Please help me understand how to deal correctly with this error: libtool: link: armflang -shared-g -soname libp2.so.0 -o .libs/libp2.so.0.0.0 armflang: error: unknown argument: '-soname' I see this issue mentioned in multiple places, e.g:

Re: armflang: error: unknown argument: '-soname'

This seems like an automake issue, not libtool. The libtool produced by running configure has: 11661 # ### BEGIN LIBTOOL TAG CONFIG: FC 11662 11663 # The linker used to build libraries. 11664 LD="/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/aarch64-linux-gnu/bin/ld"

bug#66353: bug#66354: test suite: remake-after-aclocal-m4 failure

> Indeed, these are random failures. Closing per https://bugs.gnu.org/64756. Thanks.

bug#55025: [PATCH] New "posix" automake option.

I installed your patch (and added a tiny test case). Thanks Vincent! Closing this bug (finally ...). -k

bug#66354: test suite: remake-after-aclocal-m4 failure

On 2023-10-05 15:18:39 -0600, Karl Berry wrote: > Thanks. I wonder if this and aclocal-I-and-install fail consistently for > you. There is a timing issue with development automake that requires > development autoconf (for a one-character fix in autom4te). Info: > https://bugs.gnu.org/64756.

bug#66354: test suite: remake-after-aclocal-m4 failure

remake-after-aclocal-m4 is one of the two tests that fail. I've attached the t/remake-after-aclocal-m4.log file. Thanks. I wonder if this and aclocal-I-and-install fail consistently for you. There is a timing issue with development automake that requires development autoconf (for a

bug#55025: [PATCH] New "posix" automake option.

This patch is from https://bugs.gnu.org/55025. Thanks Vincent!

bug#55025: [PATCH] New "posix" automake option.

This patch is from https://bugs.gnu.org/55025. * lib/Automake/Options.pm: declare "posix" option. * bin/automake.in: if the "posix" option is present, add a .POSIX special target as the first non-comment line in the Makefile.in files. * NEWS: mention this. * doc/automake.texi: likewise. --- NEWS

bug#66354: test suite: remake-after-aclocal-m4 failure

Under Debian/unstable, when testing the automake Git version (80714ea0aba62f025780f432abfbab2e66f6f801), remake-after-aclocal-m4 is one of the two tests that fail. I've attached the t/remake-after-aclocal-m4.log file. -- Vincent Lefèvre - Web: 100% accessible

bug#66353: test suite: aclocal-I-and-install failure

Under Debian/unstable, when testing the automake Git version (80714ea0aba62f025780f432abfbab2e66f6f801), aclocal-I-and-install is one of the two tests that fail. I've attached the t/aclocal-I-and-install.log file. -- Vincent Lefèvre - Web: 100% accessible validated

bug#66352: parallel make yields "find: ‘./conf*.dir’: No such file or directory" errors

When I want to build Automake (current Git version) with a parallel make ("make -j12"): MAKEINFO doc/automake-history.info GEN bin/automake GEN bin/aclocal GEN t/ax/shell-no-trail-bslash GEN t/ax/cc-no-c-o GEN doc/aclocal.1 GEN runtest GEN

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

On 2023-10-03 15:08:42 -0600, Karl Berry wrote: > Yes, Automake should either detect a ".POSIX:" in the Makefile.am > file (at least if it is the first non-comment line) and place it at > the beginning of Makefile.in, or provide an option to be used with > AM_INIT_AUTOMAKE (or

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

On 2023-10-02 15:17:13 -0600, Karl Berry wrote: > Sorry, I don't understand what you want Automake to do. > > Right now, as far as I can tell, Automake does nothing with .POSIX. It's > not mentioned in the manual nor, as far as I can grep, the code. Maybe > that's the issue, and you want a

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

Sorry, I don't understand what you want Automake to do. Right now, as far as I can tell, Automake does nothing with .POSIX. It's not mentioned in the manual nor, as far as I can grep, the code. Maybe that's the issue, and you want a leading .POSIX in your Makefile.am to be specially copied at the

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

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote: > Consider these two Makefiles, identical except for the presence of > the .POSIX special target: > > % cat >noposix.mk <<'EOF' > craziness: > @-false; echo hello > @false; echo hello > EOF > > % cat >posix.mk <<'EOF' > .POSIX:

Re: Detect --disable-dependency-tracking in Makefile.am

On Sun, 1 Oct 2023 at 04:45, Jan Engelhardt wrote: > >I didn't explain sufficiently. The submakes I'm talking about are my > >doing, and I want to conditionalize them on whether > >--enable-dependency-tracking is used. > > > >In for example both ntpq/Makefile.am and ntpd/Makefile.am I'm

Re: Detect --disable-dependency-tracking in Makefile.am

>I didn't explain sufficiently. The submakes I'm talking about are my >doing, and I want to conditionalize them on whether >--enable-dependency-tracking is used. > >In for example both ntpq/Makefile.am and ntpd/Makefile.am I'm invoking: > >(cd ../libntp && make libntp.a) Yes and if you didn't do

Re: Detect --disable-dependency-tracking in Makefile.am

On Sun, 1 Oct 2023 at 00:59, Nick Bowler wrote: > Suggestion 2) All explicit --enable-foo/--disable-foo arguments to > a configure script are available in shell variables; in the case of > --disable-dependency-tracking you can do something like this in > configure.ac: > >

Re: Detect --disable-dependency-tracking in Makefile.am

On 2023-09-30, Nick Bowler wrote: > Two suggestions, one relying on Automake internals and one not: > > Suggestion 1) > internal ... Automake conditional called AMDEP. [...] > Suggestion 2) [...] > AM_CONDITIONAL([NO_DEPS], [test x"$enable_dependency_tracking" = x"no"]) > Note that these

Re: Detect --disable-dependency-tracking in Makefile.am

On 2023-09-29, Dave Hart wrote: > I'm guessing someone has trod this ground before. I'd appreciate > pointers to examples of how others have detected > --disable-dependency-tracking to change their build behavior. Two suggestions, one relying on Automake internals and one not: Suggestion 1) It

Re: Detect --disable-dependency-tracking in Makefile.am

On Sat, 30 Sept 2023 at 05:07, Jan Engelhardt wrote: > On Saturday 2023-09-30 05:27, Dave Hart wrote: > > >I've added code to the ntp.org Makefile.am files to ensure the static > >utility library libntp.a is up-to-date for each program that uses it, to > >ensure the build is correct. When

Re: Detect --disable-dependency-tracking in Makefile.am

On Sat, Sep 30, 2023, at 1:07 AM, Jan Engelhardt wrote: > On Saturday 2023-09-30 05:27, Dave Hart wrote: > >>I've added code to the ntp.org Makefile.am files to ensure the static >>utility library libntp.a is up-to-date for each program that uses it, to >>ensure the build is correct. When

Re: Detect --disable-dependency-tracking in Makefile.am

On Saturday 2023-09-30 05:27, Dave Hart wrote: >I've added code to the ntp.org Makefile.am files to ensure the static >utility library libntp.a is up-to-date for each program that uses it, to >ensure the build is correct. When building the project, this adds a bunch >of extra submake invocations

Detect --disable-dependency-tracking in Makefile.am

I've added code to the ntp.org Makefile.am files to ensure the static utility library libntp.a is up-to-date for each program that uses it, to ensure the build is correct. When building the project, this adds a bunch of extra submake invocations which slows down the build. I'd like to omit those

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

Karl Berry , Tue Sep 05 2023 23:15:16 GMT+0200 (Central European Summer Time) Karl: The same problem was also reported as bug 65730, with a patch Thanks Zack. I had just composed a reply saying just about exactly the same thing as you wrote :). I will merge the patches and try Bogdan's

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

Karl: The same problem was also reported as bug 65730, with a patch Thanks Zack. I had just composed a reply saying just about exactly the same thing as you wrote :). I will merge the patches and try Bogdan's test, no problem. -k P.S. Bogdan, sorry that I wasn't thinking more clearly when I

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

> Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200 > (Central European Summer Time) >> Bogdan: I will adjust the patch, one way or another. Nothing more for >> you to do here after all :). --thanks, karl. Karl: The same problem was also reported as bug 65730, with a patch supplied by Łukasz

[bug#65730] [PATCH v2] m4: Update invocation of AC_PROG_LEX

Commit 73f1be5e42e3 to autoconf has introduced an argument to AC_PROG_LEX. Invocation without the argument has been treated as obsolete since then. * m4/lex.m4: pass the required argument to AC_PROG_LEX * doc/automake.texi: Describe it. * NEWS: Mention it --- NEWS | 2 ++

bug#65679: Request to cut new automake release to include new pythons

WDYT of cutting new `automake` that includes this fix? Then projects could start cutting release tarballs that Just Work for such systems. Agreed we need to make a new automake release asap, but unfortunately the code is not ready. Releasing it would cause more problems than it would

bug#65679: Request to cut new automake release to include new pythons

Hi automake developers! Projects using automake build system occasionally get bug reports that python 3.11 and above do not get automatically detected by AM_PATH_PYTHON([3.7]) Recent example: https://github.com/skvadrik/re2c/issues/456 It was fixed a while ago in

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200 (Central European Summer Time) One way to maintain compatibility Thank you very much, Nick. That is all excellent to know. Bogdan: I will adjust the patch, one way or another. Nothing more for you to do here after all :). --thanks, karl.

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

One way to maintain compatibility Thank you very much, Nick. That is all excellent to know. Bogdan: I will adjust the patch, one way or another. Nothing more for you to do here after all :). --thanks, karl.

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

On 31/08/2023, Karl Berry wrote: > Hi Bogdan, > > In reference to: > https://lists.gnu.org/archive/html/automake/2023-07/msg7.html. > > Thanks much! > > Since it's Autoconf 2.70 that started using the parameter, I've > bumped the required value. > > I don't think we should

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

Hi Bogdan, In reference to: https://lists.gnu.org/archive/html/automake/2023-07/msg7.html. Thanks much! Since it's Autoconf 2.70 that started using the parameter, I've bumped the required value. I don't think we should require the brand-new ac 2.70 just for this minor

[bug#65600] [PATCH] Allow parameters AM_PROG_LEX

Hi. In reference to: https://lists.gnu.org/archive/html/automake/2023-07/msg7.html. The attached patch allows the AM_PROG_LEX macro to accept parameters, to accommodate for the fact that AC_PROG_LEX now (since Autoconf 2.70) requires one. The values accepted by AM_PROG_LEX are passed to

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

Subject: [bug#59993] [PATCH v2 2/3] tests: Fix implicit function declaration errors I applied this part of the patch. Final diff as applied below. Subject: [bug#59993] [PATCH v2 3/3] tests: Fix implicit function declaration in ax/depcomp.sh Part 3 for t/ax/depcomp.sh was

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

In current version of flex, not having this header leads to implicit function declarations that are not compatible with c99 standard. On top of that, while flex dedicated test were having this macro set, the yacc ones didn't have it despise their use of Flex. For consistency,

[bug#60962] [PATCH v3] tests: Fix implicit function declaration in ax/depcomp.sh

Hi Frédéric, [in t/ax/depcomp.sh] - Replace the mv operation by a cp operation to ensure that subfoo.h is considered being modified. Thanks for the clear explanation and simple patch :). I (finally) installed it, just adding a comment, so am closing this. Happy hacking, Karl

Re: [PATCH v2] automake: rewrite scan_variable_expansions regex

The regex pattern in function scan_variable_expansions() fails to report a portability warning when a dollar-escaped dollar sign precedes the variable: foo_SOURCES = a.c $$$(patsubst a.c,a,b) Thanks much, Jan. It all worked for me. Pushed. --karl

[PATCH v2] automake: rewrite scan_variable_expansions regex

The regex pattern in function scan_variable_expansions() fails to report a portability warning when a dollar-escaped dollar sign precedes the variable: foo_SOURCES = a.c $$$(patsubst a.c,a,b) --- lib/Automake/Variable.pm | 5 +++-- t/dollarvar2.sh | 9 + 2 files changed,

[bug#65032] doc: missing bits in _DATA description

The 'Data' node doesn't list docdir and lispdir, though doc_DATA and lisp_DATA are mentioned elsewhere in automake.texi. Looks good to me. Thanks Ineiev. Installed, closing. --karl

Re: [PATCH] automake: rewrite scan_variable_expansions regex

The regex pattern in function scan_variable_expansions() fails to report a portability warning when a dollar-escaped dollar sign precedes the variable: foo_SOURCES = a.c $$$(patsubst a.c,a,b) Thanks Jan. Any chance you could add a check to one of the tests, I guess

[PATCH] automake: rewrite scan_variable_expansions regex

The regex pattern in function scan_variable_expansions() fails to report a portability warning when a dollar-escaped dollar sign precedes the variable: foo_SOURCES = a.c $$$(patsubst a.c,a,b) --- lib/Automake/Variable.pm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff

[bug#65032] doc: missing bits in _DATA description

Hello, The 'Data' node doesn't list docdir and lispdir, though doc_DATA and lisp_DATA are mentioned elsewhere in automake.texi. diff --git a/doc/automake.texi b/doc/automake.texi index 3b4f06e..d14b769 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -7355,14 +7355,16 @@ Automake

Re: Issue with AM_PROG_LEX

This will work iff AM_PROG_LEX uses AC_REQUIRE to invoke AC_PROG_LEX. Evidently so. From automake's m4/lex.m4: AC_DEFUN([AM_PROG_LEX], [AC_PREREQ([2.50])dnl AC_REQUIRE([AM_MISSING_HAS_RUN])dnl AC_REQUIRE([AC_PROG_LEX])dnl if test "$LEX" = :; then LEX=${am_missing_run}flex fi])

<    1   2   3   4   5   6   7   8   9   10   >