Re: GCC reporting piped input as a security feature

On Tue, Apr 9, 2024, at 11:35 PM, Jacob Bachmeyer wrote: > Jan Engelhardt wrote: >> On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote: >> In principle it could be posible to output something different to describe this stramge situation explicitly. For instance, output "via stdin"

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

On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote: > "Zack Weinberg" writes: >> It might indeed be worth thinking about ways to minimize the >> difference between the tarball "make dist" produces and the tarball >> "git archive" produces, sta

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

On Sun, Mar 31, 2024, at 3:17 AM, Jacob Bachmeyer wrote: > Eric Gallager wrote: >> Specifically, what caught my attention was how the release tarball >> containing the backdoor didn't match the history of the project in its >> git repository. That made me think about automake's `distcheck` >>

bug#68808: subsecond mtime discovery code insufficient

On Tue, Jan 30, 2024, at 6:32 PM, Karl Berry wrote: > test "$[*]" != "X conftest.ts1 conftest.ts2" || > .. > test "$[]2" = conftest.ts3 && > .. > etc. > > I've never seen anything like that before. Oh! Those square brackets are M4 quotes to prevent M4 from expanding $* and $2 itself. zw

bug#68808: subsecond mtime discovery code insufficient

On Tue, Jan 30, 2024, at 7:46 AM, Erik A Johnson wrote: > I found the problem! The default GNU make on macOS (even Sonoma) is > 3.81 from 2006! The configure script for GNU make versions <4.0 did > not have the right test for subsecond resolution in the macOS stat() > function, so 3.81 was built

bug#68808: subsecond mtime discovery code insufficient

On Mon, Jan 29, 2024, at 6:00 PM, Karl Berry wrote: > But, looking at that code, I belatedly see that shell arrays are being > used. At least I think so. It is absolutely not *supposed* to be using shell arrays. If it is, that was a mistake on my part. zw

Unavailable due to hardware problems

In case anyone is waiting for me to respond to questions or write a patch or anything, please be advised that my work computer has crashed hard and until replacement components arrive (early next week) I can't do much of anything.

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

On Mon, Jan 15, 2024, at 7:02 PM, Jacob Bachmeyer wrote: > Frederic Berat wrote: >> pythons="python python2 python3" >> for i in {20..0};do pythons="$pythons python3.$i";done >> for i in {7..0};do pythons="$pythons python2.$i";done >> >> m4_define_default([_AM_PYTHON_INTERPRETER_LIST], [$pythons])

bug#68274: automake 1.16j nonnumerical version confuses scripts

On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote: > On 13 Jan 2024 15:58, Karl Berry wrote: >> Another alternative: when this came up 30-odd years ago, rms changed the >> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing >> that would at least have the benefit of following

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

On Mon, Jan 8, 2024, at 7:44 AM, Karl Berry wrote: > The plethora of bug reports from the last pretest make me believe that > many systems simply cannot (currently) reliably handle a millisecond > difference in mtime. ... > My current idea is to only try for a hundredth of a second. ... > The

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

On Sat, Dec 23, 2023, at 1:54 PM, > Without Jacob's suggested use of encode(), I see (Jacob, thanks for the > explanations), but Zack, I'm not sure you intended this bug to track > that. Feel free to reopen if so. I decided I didn't want to write that code and verify it in a hurry. I'll come

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

lib/Automake/ChannelDefs.pm and lib/Automake/Channels.pm were updated in Autoconf to address . Bring over the changes. It *should* be impossible to reach report_bad_channel from code in Automake. * lib/Automake/Channels.pm (msg): If the channel argument

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

One of Autoconf's regression tests includes: # If Autoconf is too old, or the user has turned caching off, skip: AT_CHECK([aclocal || { ret=$?; test $ret -eq 63 && ret=77; exit $ret; }], [], [], [ignore]) The effect is to skip the rest of the test if aclocal's exit status is 63. This

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

m4_warn([category], [message]) passes its arguments directly to Autom4te::Channels::msg. If the category argument is not a recognized “channel”, that function will crash and emit a *Perl* stack trace, which makes it look like there’s something wrong with autoconf or autom4te, rather than

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

On Fri, Dec 15, 2023, at 6:52 PM, Karl Berry wrote: > Hi Zack, > > Since this touches code shared between Autoconf and Automake, I'm not > checking it in yet and I'm requesting comments from both sides of the > fence. > > Well, it seems good to me in principle, FWIW. I don't think this

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

On Fri, Dec 15, 2023, at 7:08 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> [...] >> Also, there’s a perl 2.14ism in one place (s///a) which I need >> to figure out how to make 2.6-compatible before it can land. ... >> + $q_channel =~ s/([^\x20-\x7e])/"\

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

In autoconf 2.69, the manual said that you could use “all” and the empty string as the first argument to m4_warn. As far as I can tell this was never actually true, and the manual was corrected in 2.70, but we still got a bug report from someone who tried it and got a confusing internal error

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

In order for the Automake testsuite to be able to use sub-second delays to control whether certain files are considered newer than others, five(!) separate pieces of software all need to cooperate: automake itself, autoconf’s internal “autom4te” utility, the Perl interpreter and its libraries, the

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

On Tue, Dec 5, 2023, at 11:30 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> $ autom4te --version >> autom4te (GNU Autoconf) 2.71 >> Features: subsecond-timestamps >> >> Copyright (C) 2021 Free Software Foundation, Inc. >> License GPLv3+/Autocon

[PATCH v2, committed] autom4te: report subsecond timestamp support in --version

The Automake test suite wants this in order to know if it’s safe to reduce the length of various delays for the purpose of ensuring files in autom4te.cache are newer than the corresponding source files. We can also take advantage of this to speed up a couple of tests in our own testsuite. *

Re: rhel8 test failure confirmation?

On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: [snip everything addressed in the other thread] > Yes, there was a bit of confusion here; not only is the FileUtils > module synchronized between autom4te and automake Thanks for reminding me that I need to

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote: > Now that I have seen the actual patch, yes, this test should be > accurate. The test in the main autom4te script will also work, even > if there is a mismatch between the script and its library Good. > This appears to be misaligned with

[RFC PATCH]: autom4te: report subsecond timestamp support in --version

The Automake test suite wants this in order to know if it’s safe to reduce the length of various delays for the purpose of ensuring files in autom4te.cache are newer than the corresponding source files. * lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag $subsecond_mtime, indicating

Re: rhel8 test failure confirmation?

On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote: >> There would not need to be much parsing, just "automake --version | grep > > HiRes" in that case, or "case `automake --version` in *HiRes*) ...;; > > easc" to avoid running grep if you want. > > I specifically want to hear what

Re: rhel8 test failure confirmation?

On Sat, Dec 2, 2023, at 8:58 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> Either way is no problem from my end, but it would be more work >> for automake (parsing --version output, instead of just checking the >> exit status of autom4te --assert-high-resolution-times

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

On Sat, Dec 2, 2023, at 9:08 PM, Mike Frysinger wrote: > On 02 Dec 2023 15:53, Karl Berry wrote: >> Exit status yes, but at least historically, grep -q has been >> considered non-portable, in favor of grep ... >/dev/null. > > i get that `grep -q` is something historically we've avoided, but i >

Re: rhel8 test failure confirmation?

On Sat, Dec 2, 2023, at 7:33 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> Would it help if we added a command line option to autom4te that made >> it report whether it thought it could use high resolution timestamps? >> Versions of autom4te that didn't recogni

Re: rhel8 test failure confirmation?

On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote: > The best way to check if high-resolution > timestamps are available to autom4te is to have perl load > Autom4te::FileUtils and check if that also loaded Time::HiRes. > > The problem with that turned out to be that Time::HiRes got

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

[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#64968: automake --version isn't work

On Mon, Jul 31, 2023, at 1:39 PM, Zack Weinberg wrote: > On Mon, Jul 31, 2023, at 2:02 AM, 874882199--- via Bug reports for > Automake wrote: >> In Docker(in the vmware ubunt also has the problem): >> Environment: >> Ubuntu 20.04 5.15.0-78-generic. >> Automake1.4 f

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

On Mon, Jul 31, 2023, at 2:02 AM, 874882199--- via Bug reports for Automake wrote: > 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. This is a very old version of

Re: Issue with AM_PROG_LEX

On Mon, Jul 31, 2023, at 7:37 AM, FX Coudert wrote: > Hello, > > I have a configure.ac file that calls AM_PROG_LEX. This now generates > warnings: ... > I am not sure I can actually fix those: AM_PROG_LEX does not seem to > accept an argument. Probably it should, and pass it down to AC_PROG_LEX

bug#63052: Bug Mite have been found

On Mon, Apr 24, 2023, at 5:46 AM, Travis Goff wrote: > /kalibrate-rtl$ bash /usr/share/automake-1.16/missing --help > [... help output ...] Could you please explain what went wrong here? Be as specific as possible. What do you think happened, and what do you think should having happened instead?

Re: rhel8 test failure confirmation?

On Tue, Apr 4, 2023, at 3:51 PM, Bogdan wrote: > Nice. The 0 and 1 may not be portable to each OS in the Universe > (see EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be > good/portable enough for our goals. Or maybe some other simple solution. ISO C guarantees that exit(0) has the

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

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

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

On Sat, Jan 14, 2023, at 7:18 PM, Mike Frysinger wrote: > Rather than assume such coarse delays, re-use existing logic for > probing the current filesystem resolution. This speeds up the > testsuite significantly. On my system, it speeds -j1 up quite a > lot -- by ~30%. While I didn't gather

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

On Fri, Jan 13, 2023, at 6:33 PM, Karl Berry wrote: >> your patch *and* consistently test flex with "--never-interactive". > > Making flex non-interactive sounds desirable in any case, but > --never-interactive is not mentioned in the 2.6.0 --help message. > Instead there is -B (--batch), although

Re: Builds with 'configure' not at the top of srcdir

On Thu, Jan 12, 2023, at 9:24 PM, Eduardo Hernández wrote: > I've been trying to separate the build system and source directory > completely. Part of that would be to have the 'configure' script in the > 'build' directory, away from the 'src' directory This goes against a basic design assumption

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

On Thu, Jan 5, 2023, at 6:47 PM, Karl Berry wrote: > Please excuse my curmudgeonness, but it's not clear to me that avoiding > sed is worth these hassles in working around the implementation-specific > bugs in the automatic variables. It seems to me that this would be worth doing *if* we could

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On Thu, 15 Dec 2022 11:48:44 -0500, Frederic Berat wrote: > On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote: > > > return yylex (); > > Please change `int main ()` to `int main (void)` as long as you're in here. > I'm hesitant on this. That isn't the purpose of the pa

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

On Thu, Dec 15, 2022, at 2:12 AM, Frederic Berat wrote: > For the record: > > cat > less.c <<'END' > /* Valid C but deliberately invalid C++ */ > int main (void) > { > int new = 0; > return new; > } > END > > $> g++ less.c > less.c: In function ‘int main()’: > less.c:4:7: error: expected

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On Tue, Dec 13, 2022, at 1:30 AM, Frederic Berat wrote: > On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote: >> > --- a/t/ax/depcomp.sh >> > +++ b/t/ax/depcomp.sh >> > @@ -243,6 +243,7 @@ cat > sub/subfoo.h <<'END' >> > #include >>

[bug#59991] [PATCH 0/2] Port tests to modern C

On Mon, Dec 12, 2022, at 5:57 PM, Karl Berry wrote: > Zack, would you like be co-maintainer or at least co-developer of > Automake? There is, evidently, no one else in the world interested in > being actively involved with Automake on the maintainer side. I have to decline; I don't have anything

Re: [bug#59991] [PATCH 0/2] Port tests to modern C

On Mon, Dec 12, 2022, at 5:57 PM, Karl Berry wrote: > Zack, would you like be co-maintainer or at least co-developer of > Automake? There is, evidently, no one else in the world interested in > being actively involved with Automake on the maintainer side. I have to decline; I don't have anything

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

On 2022-12-12 2:07 AM, Frederic Berat wrote: This patch is mainly a proposal. While the macro can simply be removed as explained below, another possibility it to add a flex option "--never-interactive" to prevent flex to make use of "isatty". This is related to an effort to prepare Automake

[bug#59993] [PATCH 2/2] tests: Fix implicit function declaration errors

On 2022-12-12 2:05 AM, Frederic Berat wrote: This is related to an effort to prepare Automake for future GCC/Clang versions which set c99 as default standard to be used. Function should be properly declared prior to use in order to be compatible with c99 standard. OK in principle, but ...

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

On 2022-12-12 2:05 AM, Frederic Berat wrote: This is related to an effort to prepare Automake for future GCC/Clang versions which set c99 as default standard to be used. Not properly declaring main as "int main(...)" is rejected since c99. ... /* Valid C but deliberately invalid C++ */ -main

Re: Question WHY is gnu make does not stop on error on rule

On Thu, Dec 8, 2022, at 5:18 AM, aotto wrote:> Hi, > I use "automake" to setup a "gnu make" build-environment and I have the > following rule to create a special file: > Problem: the "$(c_Meta)" failed with error but MAKE continue… why?? ... > $(csmkkernel_meta) $(csmqmsgque_meta)

Re: make check(s) pre-release problems

Please don't top-post on this mailing list. On Tue, Oct 11, 2022, at 12:15 PM, Frederic Berat wrote: > On Fri, Oct 7, 2022 at 6:11 PM Zack Weinberg wrote: >> On Thu, Oct 6, 2022, at 4:25 PM, Karl Berry wrote: >>>> No errors on RHEL7+autoconf2.71 >>> >>> Pu

_AM_FILESYSTEM_TIMESTAMP_RESOLUTION incorrect result (was Re: make check(s) pre-release problems)

On Thu, Oct 6, 2022, at 4:19 PM, Zack Weinberg wrote: > On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote: >> On 2022-10-04 6:58 PM, Karl Berry wrote: >>> Perhaps easier to debug: there are two targets to be run before making a >>> release, check-no-trailing-backsl

Re: make check(s) pre-release problems

On Thu, Oct 6, 2022, at 4:25 PM, Karl Berry wrote: > No errors on RHEL7+autoconf2.71 > > Puzzling. Can you easily try RHEL8 or one of its derivatives? > It surprises me that that is the culprit, but it seems possible. Unfortunately, no. CMU is mostly an Ubuntu shop these days. It's only dumb

Re: make check(s) pre-release problems

On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote: > On 2022-10-04 6:58 PM, Karl Berry wrote: >> Perhaps easier to debug: there are two targets to be run before making a >> release, check-no-trailing-backslash-in-recipes and check-cc-no-c-o, >> to try to ensure no reversi

Re: make check(s) pre-release problems

On 2022-10-04 6:58 PM, Karl Berry wrote: With Zack's latest Python fixes, I was hoping to move towards an Automake release, but I find myself stymied by apparently random and unreproducible test failures. I haven't exhausted every conceivable avenue yet, but I thought I would write in hopes that

Re: python debugging on trunk

On Mon, Sep 26, 2022, at 12:23 PM, Karl Berry wrote: > Is anyone up for debugging some Python-related test failures on > RHEL-based systems? I have access to a RHEL7 system, I know Python, and this sounds much less unpleasant than everything else I'm supposed to be doing today. > I have a

bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is used

On Sat, Sep 24, 2022, at 5:45 AM, Richard Hopkins wrote: > On 2022-09-23 16:15, Zack Weinberg wrote: >> Thank you for the patch. Are you able to test it with a version of >> GNU Emacs older than 23.2? I see that you tested it with XEmacs 21, >> but as I recall there w

bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is used

On Fri, Sep 23, 2022, at 8:24 AM, em...@unbit.co.uk wrote: > The attached `git format-patch` is based on automake v1.16.5 and fixes > the following warning > > Warning (bytecomp): byte-compile-dest-file is obsolete (as of 23.2); > Set byte-compile-dest-file-function instead. > > The

bug#32868: Check if make supports nested variables is done twice when using silent rules

> i'm inclined to bring this back as the way to opt-in to silent-rules > by default. And I’m still absolutely opposed to making it even *possible* to have silent rules be on by default. In fact I’d like to see —enable-silent-rules removed, with make V=0 the *only* way to switch to silent mode.

Re: bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early

On Wed, Feb 9, 2022, at 1:02 AM, Mike Frysinger wrote: > On 08 Feb 2022 22:11, Glenn Morris wrote: >> >> I see autoconf uses savannah for bug reports. >> So long as simply sending a mail to bug-autoconf doesn't open a savannah >> issue, >> I can set the autoconf maintainer to bug-autoconf, so

Re: [PATCH] python: prioritize python 3.x over 2.x

On Thu, Jan 27, 2022, at 9:20 PM, Jacob Bachmeyer wrote: >> Now, nobody listens to me, and I'm painfully aware that "python" >> pointing to Python 3 is common, but that doesn't mean Autotools should >> make the situation even worse. Autotools should, on its own motion, >> discourage the use of

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 10:10 PM, Mike Frysinger wrote: > On 26 Jan 2022 10:07, Zack Weinberg wrote: >> Please also move the plain "python" command down to the python2 >> block (right after "python2" would be the best place I think). Any >> system o

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 10:07 AM, Zack Weinberg wrote: > On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote: >> Since Python 2.x went EOL years ago, stop searching for it before >> any of the Python 3 versions. > > +1 It occurred to me right after pushing "send&q

bug#53530: [PATCH] python: add 3.10 - 3.15 to the version search list

On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote: > Fixes automake bug https://bugs.gnu.org/53530. > > Based on the cadence of Automake releases, add the current Python > release (3.10), the current Python development (3.11), and then 4 > more versions on top of that. It doesn't hurt to

Re: [PATCH] python: prioritize python 3.x over 2.x

On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote: > Since Python 2.x went EOL years ago, stop searching for it before > any of the Python 3 versions. +1 >m4_define_default([_AM_PYTHON_INTERPRETER_LIST], > -[python python2 python3 dnl > +[python python3 dnl > python3.15 python3.14

bug#31728: [PATCH] dmalloc: mark macro as obsolete

On Sat, Jan 22, 2022, at 4:44 PM, Karl Berry wrote: > Sorry, I still disagree with "deprecating" AM_WITH_DMALLOC (or anything > else). My wish would be to add some strong wording in the manual about > how it doesn't do anything especially useful, new code shouldn't use it, > etc., and let it go at

Re: [PATCH 1/2] m4: warn when AM_SILENT_RULES default is used

On Sun, Dec 12, 2021, at 1:09 AM, Mike Frysinger wrote: > To help ease people into enabling silent rules by default, warn if > a package doesn't make an explicit selection. -1 for the same reason that changing the default is a bad idea. If we are to make *any* change in this area I would

Re: [RFC/PATCH] m4: enable silent build rules by default

On Sun, Dec 12, 2021, at 1:10 AM, Mike Frysinger wrote: > On 07 Dec 2021 21:58, Zack Weinberg wrote: >> On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: >> > This has been available since automake 1.11 released over a decade >> > ago. Let's flip the defa

Re: [PATCH] gitignore: update

On Sun, Dec 12, 2021, at 1:07 AM, Mike Frysinger wrote: > Ignore all *~ files as editors like to create them, as do some > autotool steps. This also matches what autoconf is doing. ... > +*~ > +.#* Suggest also adding \#*# (emacs autosave files) and .*.sw[op] (vim autosave files). zw

Re: [RFC/PATCH] m4: enable silent build rules by default

On Tue, Dec 7, 2021, at 9:49 PM, Mike Frysinger wrote: > This has been available since automake 1.11 released over a decade > ago. Let's flip the default to enable silent builds by default. Please don't *ever* make this change. It is absolutely essential that the default build output be

Re: `make dist` fails with current git

On Wed, Oct 13, 2021, at 2:32 PM, Nick Bowler wrote: > On 2021-10-13, Zack Weinberg wrote: >> On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote: >>> I think this happened because your CI system has done a shallow clone. >>> So the changelog generation failed becaus

Re: `make dist` fails with current git

On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote: > I think this happened because your CI system has done a shallow clone. > So the changelog generation failed because the git log is incomplete. I did a --single-branch clone, but not a shallow one. Shouldn't the trunk be self-contained? zw

Re: `make dist` fails with current git

On Wed, Oct 13, 2021, at 11:54 AM, Bob Friesenhahn wrote: > On Wed, 13 Oct 2021, Zack Weinberg wrote: >> >> Looks like some kind of problem with automatic ChangeLog generation? > > To me this appears to be the result of skipping an important step in > what should b

`make dist` fails with current git

$ make V=1 dist make dist-xz dist-gzip am__post_remove_distdir='@:' make[1]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake' make distdir-am make[2]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake' set -e; set -u; \ if test -d ../s-automake/.git; then \

bug#50469: [bison-3.8] bug or side effect to flex & automake

On Wed, Sep 8, 2021, at 1:31 AM, Akim Demaille wrote: > One big problem with the Autotools as of today is that they promote > the use of macros/build rules for Yacc, not for Bison. The contract of AC_PROG_YACC is to find something that will generate parsers from POSIX-compliant input; all three

Re: [PATCH] dist: add new "pure-dist" automake option

On Fri, Jul 2, 2021 at 11:09 AM Allison Karlitskaya wrote: > > Since v1.15.1-204-gac47c22e3, "make dist" has been depending on > $(BUILT_SOURCES) to avoid problems when building some GNU packages which > need to compile themselves as part of building their tarballs (for > example, to generate

Re: config.sub/config.guess using nonportable $(...) substitutions

On Tue, Mar 9, 2021 at 5:00 PM Tim Rice wrote: > On Tue, 9 Mar 2021, Warren Young wrote: > > On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote: > > Solaris 10 dates from early 2005. We gave it 16 years of direct support, > > and now it’s on a sort of “extended” support if you point Autoconf > >

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote: I don't know why, but I only received this message today. > But, I think it would be wise to give users a way to override the > requirement, of course with the caveat "don't blame us if it doesn't > work", unless there are true requirements such

Re: RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote: I don't know why, but I only received this message today. > raise the minimum version requirement for Perl to 5.18.0 > > Sounds sensible to me, for the reasons you outlined. > > But, I think it would be wise to give users a way to override

Re: Automake's file locking

On Thu, Jan 28, 2021 at 6:51 PM Bruno Haible wrote: > Zack Weinberg wrote: > > There is a potential way forward here. The *only* place in all of > > Autoconf and Automake where XFile::lock is used, is by autom4te, to > > take an exclusive lock on the entire conte

Re: automake variable prefix 'check_'

On Tue, Feb 2, 2021 at 1:24 PM DUDZIAK Krzysztof wrote: > As one can't find string "distcheck" in GCS By GCS do you mean the GNU Coding Standards? > it looks like it wasn't GCS > which constitutes support and usage of `distcheck' target. > Maybe it is POSIX, or UNIX. As far as I know, the

Re: PLV, PSV in manual

On Tue, Feb 2, 2021 at 1:19 PM DUDZIAK Krzysztof wrote: > Isn't it that strange if for manual* following searches for a string result > in no matches? > search for "PLV" > search for "PSV" > search for "Product List Variable" > search for "Product Source Variable" I've never heard these terms

RFC: Bump minimum Perl to 5.18.0 for next major release of both Autoconf and Automake

I propose that, as of the next major feature release of both Autoconf and Automake, we raise the minimum version requirement for Perl to 5.18.0. (Currently it is 5.6.0.) On the Autoconf side, the version number and timeframe for the first release with this change are still TBD but it would *not*

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn wrote: > On Thu, 28 Jan 2021, Zack Weinberg wrote: > > > > The main reason I can think of, not to do this, is that it would make > > the locking strategy incompatible with that used by older autom4te; > > this could come

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn wrote: > On Mon, 25 Jan 2021, Zack Weinberg wrote: > > Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in > > Automake/XFile.pm) (this code is copied into Autoconf under the > > Autom4te:: name

Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn wrote: > At the moment it is a big deal for me because the locking prototol > that Autoconf/Automake is using does not work with NFS mounts for > Illumos-derived systems when the client is also an Illumos-derived > system, because Illumos failed to

Re: Future plans for Autotools

On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote: > Now we've all had a while to recover from the long-awaited Autoconf > 2.70 release, I'd like to start a conversation about where the > Autotools in general might be going in the future. > Now we've all had a while to recover f

Future plans for Autotools

Now we've all had a while to recover from the long-awaited Autoconf 2.70 release, I'd like to start a conversation about where the Autotools in general might be going in the future. Clearly any future development depends on finding people who will do the work, but before we worry about that I

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

On Tue, Jan 5, 2021 at 8:43 AM Bob Friesenhahn wrote: > On Mon, 4 Jan 2021, Zack Weinberg wrote: > >> > >> Something which surprises me is that the distribution tarballs became > >> noticeably larger. > > > > This is expected. The bulk of the increase is

Re: Build and test failures with Autoconf 2.70

Karl Berry wrote: > Zack Weinberg wrote: >> They all appear to be cases of autoconf and/or aclocal >> getting run when the test suite does not expect them to be run. I am >> stumped as to why > > In short: because the 2.70 autom4te decided not to update configure. >

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On Wed, Oct 28, 2020 at 4:00 PM H.J. Lu wrote: > On Wed, Oct 28, 2020 at 11:40 AM Nick Bowler wrote: > > On 2020-10-28, Zack Weinberg wrote: > > > On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote: > > >> On 2020-10-28, H.J. Lu wrote: > > >> &

Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler wrote: > On 2020-10-28, H.J. Lu wrote: > > GCC introduced some time ago option -flto=jobserver in order to use the > > GNU Make jobserver when parallelising LTO builds. It is actually a > > similar "recursive make". When doing a recursive make, you

Re: AC_DIAGNOSE not obsolete, please

Both sets of patches have been pushed. The changes to the Autoconf manual are slightly different in the version I committed, I found some small errors on proofreading the patch. According to https://codesearch.debian.net/search?q=-pkg%3Aautoconf+%5CbAC_DIAGNOSE%5Cb=0 this would have been a

Re: AC_DIAGNOSE not obsolete, please

On Mon, Oct 5, 2020 at 5:40 PM Karl Berry wrote: > > Zack and all - Thien-Thi (cc'd) just reported two failures in automake > make check with autoconf-2.69c (bugs.gnu.org/43819). The critical > message appears to be: > > ./lib/autoconf/general.m4:2328: AC_DIAGNOSE is expanded from... >

[RFC PATCH 1/3] New utility function Automake::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not

[RFC PATCH 3/3] Update documentation of warnings options and strictness levels.

The warning categories ‘cross’ and ‘portability-recursive’ were not mentioned in the manual. Also clarify the relationship between warnings categories and strictness levels, and streamline the description of strictness levels by merging the “Gnits” section into the “Strictness” section. *

[RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

org/archive/html/autoconf-patches/2020-09/msg8.html> for the rationale for merge_WARNINGS, which is not used in automake, but will be in autoconf. Zack Weinberg (3): New utility function Automake::ChannelDefs::merge_WARNINGS. Use WARNINGS=none to suppress warnings from autom4te runs.

[RFC PATCH 2/3] Use WARNINGS=none to suppress warnings from autom4te runs.

aclocal uses autom4te in trace mode to scan configure.ac for macros whose definition is not yet available. It has a kludge to prevent this from producing spurious warnings, but a cleaner, fully backward compatible, way to get the same effect is to set WARNINGS=none in the environment and not pass

[RFC PATCH 3/6] Disable all warnings when running autoconf as a subprocess.

autoheader and autoscan both run autoconf in trace mode, and autoheader makes a point of passing down the warnings options. This means autoheader prints warnings that a regular invocation of autoconf would also print, so in the common case where both are being run by autoreconf, the warnings are

[RFC PATCH 6/6] Autoupdate AC_{DIAGNOSE, FATAL, OBSOLETE, WARNING} and _AC_COMPUTE_INT.

While working on the previous patches I noticed that all of these macros are officially obsolete, but autoupdate doesn’t replace them. _AC_COMPUTE_INT is easy to autoupdate. AC_{DIAGNOSE,FATAL,WARNING} require a little special handling because their replacements are m4sugar macros, and

  1   2   >