bug#68855: wording for user on test suite failure?

I was thinking about making the message when the test suite failure more explicit ... (lib/am/check.am) +echo "Some test(s) failed. Please report this to $(PACKAGE_BUGREPORT),"; \ +echo "together with the test-suite.log file (gzipped) and your system"; \ +echo

[bug#68855] wording for user on test suite failure?

I was thinking about making the message when the test suite failure more explicit about what to do, as in below. If any comments or criticisms, let me know. I was actually inspired to do this not so much to tweak these words, but because I was thinking of adding yet more instructions about how to

[bug#68746] system information in test-suite.log?

I installed this change to emit system info in test-suite.log. I tried to write it so any failure would be ignored, since it's not critical information. We'll see. -k

[bug#68746] system information in test-suite.log?

I had the idea that it would be helpful to put basic system information into test-suite.log, as shown below. Although most people reporting bugs are good about including their system info, not everyone does. And details are good. I figured the output of uname -a and /etc/os-release || /etc/issue

bug#68674:

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

Guess it's time to close this one about the Python scheme to use with Debian. We'll see how it turns out with the next pretest ... --thanks, karl.

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

Guess it's time to close this one about the subsecond mtimes, and we'll see what happens next time. (For reference: see also https://bugs.gnu.org/68325 where we don't try for a millisecond any more ...)

[bug#68674] recommending autoreconf -f when version mismatch

The patch below changes the wording of the "version mismatch" errors to recommend running autoreconf -f. If anyone sees any problems with the idea, or the wording, let me know. I discovered this when trying out the last automake pretest. After configuring with the new automake, I then went back

bug#68037:

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

Hi Stefano, I'm not aware of anyone else using posix_local. Well, I don't know how to check for the deb_system scheme being present, so I made the assumption. How does this change look? Are the descriptions correct? I also pulled out the common "scheme-setting" code into a variable.

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

Hi Stefano, returning automake behaviour back to what it used to be. That seems like a good outcome to me. I wasn't actually looking to improve on that result :). if default_scheme == 'posix_local': # Debian posix_local only exists on Debian, not any other system? The name is generic.

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

Gianfranoc, Stefano - thanks much for the patch wrt Automake and Debian Python posix_local vs. posix_prefix. Below is what I installed -- the code change is substantively the same as what you wrote; I just took the extra try..catch that Bogdan added. I changed the paragraph in the manual about

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

I installed the change to only try for a hundredth of a second. We'll see if it helps. -k

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

Sorry to be a curmudgeon, but I don't see an advantage to merely dynamically synthesizing the static list of versions. If anything, I think statically listing everything in text is clearer and less error-prone. What would be an improvement is to not to have this list of versions at all. I guess

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

With Python 3.12 out now, and 3.13 out in ~9 months, the existing runway is running out. Bump up to 3.20 for the next Automake release. Applied, thanks. Not proposing to try anything for our upcoming release, but I wonder if there is some more general way to handle Python versions? We

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

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. Despite the latest careful test that Zack implemented _AM_FILESYSTEM_TIMESTAMP_RESOLUTION, pretesters continued to report "random"

bug#68066: [PATCH] Support nanoMIPS architecture

+ | nanomips* \ Thanks, but config.{sub,guess} patches need to be sent to config-patc...@gnu.org. I forwarded your message. --all the best, karl.

[bug#68037] silent-defaults.sh test needs to rerun automake

M_INIT_AUTOMAKE. +#  +echo "User enables silent mode default after AM_INIT_AUTOMAKE." cat <configure.ac -AC_INIT([silent-defaults], [1.0]) +AC_INIT([silent-defaults-user-enable-after-am_init], [1.0]) AM_INIT_AUTOMAKRunning command: git commit \-q \-F \.\/vc\-dwim\-log\-ZjLUtH \

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

One more follow-up on this. As we saw from the bug reports for the 1.16i pretest (67894, 67918), the random parallelization failures were back after this, when autom4te did not support subsecond-mtimes. As far as I could tell, what was needed was to add am_cv_sleep_fractional_seconds=false

[bug#68004] [PATCH] doc: update location of FETCHFILES variable

* HACKING: FETCHFILES has been moved: Makefile.am -> maintainer/maint.mk Thanks Dimitri. Installed (I tweaked a couple more words while we were there). (Also closing.) --all the best, karl.

[bug#68003] [PATCH] doc: typos from codespell.

Subject: [bug#68003] [PATCH] doc: typos from codespell. Thanks Dimitri. Installed as-is. (And closing.) --all the best, karl.

[bug#67868] intentionally unreadable dirs make distcheck fail

I guess no one saw anything obviously wrong with my distcheck permission fixes (or no one read my screed, for which I wouldn't blame anyone :), so closing. I still have no clue as to why it started failing "all of a sudden", but I guess it doesn't really matter. -k

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

This was changed in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67971 and autoconf-2.72 has been released, so closing. 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.

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

lib/Automake/ChannelDefs.pm and lib/Automake/Channels.pm were updated in Autoconf to address . Thanks Zack. Installed. BTW, the automake THANKS file has your panix.com address. Is that still ok, or should I update it to owlfolio? (Not that it

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

"All possible characters have a UTF-8 representation so this function [encode_utf8] cannot fail." What about non-characters, i.e., byte sequences that are invalid UTF-8? What I found was that using \N{...} implies a Unicode string. From the charnames(3) man page (stranged not named

[bug#67868] intentionally unreadable dirs make distcheck fail

(Sorry, long message.) As of a few days ago, in a normal working directory, running make distcheck twice immediately fails the second time (for me): if test -d "automake-1.16i"; then find "automake-1.16i" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "automake-1.16i" || { sleep 5 &&

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

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 directly affects automake? I admit I did not try to extract the

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

In order for the Automake testsuite to be able to use sub-second delays [...] I installed the patch (plus a tweak to NEWS). (make check and distcheck ran fine for me, including using the subsecond feature.) I included all the commentary from your message, Zack, since I thought it would

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

I guess I don't see any harm in keeping the link to POSIX. Perhaps it should be in the Autoconf manual, but either way seems ok to me. Since the OP went to the trouble of looking it up. --best, karl.

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

Thanks so much, Zack. I will review and apply, most likely tomorrow. -k

[bug#67498] Fixes for Windows

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

[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#67498:

[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

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

[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

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

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

[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

bug#60808:

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

Hi Mike, +MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution I belatedly installed this patch. (I thought you already had.) Thanks! 2023-07-14 Mike Frysinger automake: set test delays to am_cv_filesystem_timestamp_resolution. This patch is from https://bugs.gnu.org/60808. *

[bug#62886] Unnecessary bug registered

Closing bug as suggested. Mailing or cc-ing -d...@debbugs.gnu.org will close a bug. To be closed/deleted, just like https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60419. Merging that one. --thanks, karl.

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

However, neither in this mail, nor in your original did I find a corresponding patch. Hi Jim - they ended up with separate bug#s, since separate emails. At least I think these are those: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59992 (applied by mike?)

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

i'll note that Automake tests have been using `if ! ...` since 1.12 (2012), The automake *tests* intentionally use modern shell syntax and functionality, because they go to a lot of trouble to set up an environment where those are supported, via test-init.sh. t/README talks about this

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

most of the code directly preceding & following this line use @. i.e. the vast majority of the current distdir logic. Yeah. If you feel like changing those @'s to AM_v_at while we're here, sounds good to me ... -k

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

imo we overly rely on explicit @ in many places which can make debugging failures painful. FWIW, I agree. Although I see no @ here. if we ever get to that day, we'd use $(AM_V_at) in this location. Ok by me. --thanks, karl.

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

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

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

-case $build in - *-pc-msdosdjgpp) MODIFICATION_DELAY=5;; - *) MODIFICATION_DELAY=2;; -esac +MODIFICATION_DELAY=$am_cv_filesystem_timestamp_resolution Looks fantastic to me :). --thanks, karl.

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

The *command line option* --never-interactive was added in version 2.5.6 (along with long command line options in general). That version was released somewhere between 2002-04-19 and 2002-04-23; I guess 20 years ago is long enough, barely :). Though if it's just as easy to use the

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

Subject: [bug#60772] [PATCH] tests: rework gettext to only check 'external' behavior Good catch, thanks. Please commit. +# po/ is required. intl/ should not be used. Perhaps add the bit of information from your mail to help future sleuths: "... not be used, since non-external use

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

> 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 --never-interactive is recognized, I can see

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

- test -d "$(distdir)" || mkdir "$(distdir)" + $(AM_V_at)$(MKDIR_P) "$(distdir)" Ok by me, but why the AM_V_at for this particular command? I don't see it used anywhere else in distdir.am. - test -d "$$am__dir" || $(MKDIR_P) "$$am__dir" || exit 1; \ + $(MKDIR_P)

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

- (cd "$am_top_srcdir" && git log -1) || st=1 + (cd "$am_top_srcdir" && git --no-pager log -1) || st=1 Sure. Please commit. Thanks. -k

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

-done | sed 's,^\./,,' | sort | uniq >$(am__tfs); \ +done | sed 's,^\./,,' | sort -u >$(am__tfs); \ Sure, looks good, please commit. (60764 looks like a dup?)

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

Well, stated more positively, my concern is about not replacing a bunch of (granted) complicated old code with a bunch of complicated new code, i.e., creating new-and-different maintainer and portability hassles, for the sake of (what nowadays feels to me like) a micro-optimization. Let's not

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

- . "\t\@: > $dirstamp\n"); + . "\t\@: >>$dirstamp\n"); No objection from me. Go for it. Thanks. -k

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

There shouldn't be any concerns about portability with $(@D) because: (1) We only generate this rule iff we know the dirstamp is in a subdir (so we'd never have a case where $(@D) would expand to the cwd) (2) We already rely on $(@D) in our depdir code, and have since 2014

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

Fixes automake bug https://bugs.gnu.org/10828. Hi Mike - this change looks good to me. Good catches finding these. Please commit. --thanks, karl.

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

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

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

distclean: - %DISTRMS% +%DISTRMS% maintainer-clean: - %DISTRMS% +%DISTRMS% Sure, looks good. Please commit. Thanks Mike. -k

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

When the code that used this variable was removed, the variable itself was left behind. Clean that up now too. * lib/am/check.am: Delete trs_list. I can't find when the code using trs_list was removed (no mention in any ChangeLog), but indeed, grepping the current sources, I don't

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

There is ongoing work from both GCC and Clang community to set the C99 standard as the default one, Sounds inevitable. in an effort to improve security overall. How does C99 improve security? Just wondering. failures in Automake, that are attempted to be fixed, mainly in this

bug#59989: [PATCH] tests: Fix txinfo-include test for texinfo 7.x

Hi Frederic, Texinfo modified its behavior regarding apostrophes, which are now replaced by UTF-8 right single quotes by default. Sorry to hear it, but not surprised. -GNU's Not Unix. +@verb{.GNU's Not Unix..} I don't think there's any guarantee that verb quotes will also be

[bug#58336] [PATCH] HACKING: allow backward compatibilities again

Subject: [PATCH] HACKING: allow backward compatibilities again :) Thanks, I applied the fix.

[bug#54412] [PATCH] python: use the posix_prefix sysconfig scheme on Debian

Stefano, Gianfranco - thanks for this. Forgive my ignorance, but I don't use Debian, or Python, and have never the term "sysconfig scheme" before. Does your patch change the default behavior of Automake? I gather not, but ... Also, it feels like there should be some documentation about this. Can

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

@item AC_PROG_LIBTOOL +@itemx LT_INIT By all means. Thanks.

[bug#54073] [PATCH] tests: log autoconf & libtool version

why would we care about the version installed in the host system when we're compiling a new one We don't. But: this is just for the test suite. that way when people file reports & attach test-suite.log, this test is included with extended system info ... I guess the version

[bug#54073] [PATCH] tests: log autoconf & libtool version

+$AUTOCONF --version +$AUTOCONF --help +libtoolize --version +libtoolize --help Sure, all to the good. Do we already log the automake version? What log is this, anyway :)?

[bug#54022] [PATCH] python: fix exit status handling with uninstall

* lib/am/python.am: Fix final subshell exit status passing. Looks good to me, FWIW. -k

[bug#53950] [PATCH] m4: cache build env sanity checks

Subject: [bug#53950] [PATCH] m4: cache build env sanity checks Sounds fine to me. Thanks.

[bug#53649] [PATCH] maint: include versioned manual in update

Subject: [bug#53649] [PATCH] maint: include versioned manual in update Seems fine. I think you can go ahead and immediately commit these patches without a review first. Will see it in the commit email ... --thanks, karl.

[bug#53650] [PATCH] AM_PROG_AR: require before AC_PROG_AR

+AC_BEFORE([$0], [AC_PROG_AR])dnl Seems fine. I take your word for it :).

Re: [PATCH] tests: remove spurious +x bits

Subject: [PATCH] tests: remove spurious +x bits Sure, sounds good. Thanks. -k

Re: [PATCH v2] aclocal: add --aclocal-path option to override $ACLOCAL_PATH

+ --aclocal-path=PATHS colon-separated paths to search for third-party + local files Maybe "colon-separated list of directories". Or "colon-separated path". +@item --aclocal-path=@var{dir} @var{dir} -> @var{path} +@opindex --aclocal-path +Look for

Re: patch tracking

what if we had it also watch automake-patches ? would that be a least terrible option ? Hey, sounds like a good idea to me! If Jim doesn't see a problem with it, could you email help-debb...@gnu.org in a couple of days and request it? Thanks.

Re: [PATCH] aclocal: add --aclocal-path option to override $ACLOCAL_PATH

Hi Mike, * bin/aclocal.in: Add --aclocal-path to override ACLOCAL_PATH. FWIW, looks almost fine to me. 1) Please add NEWS entry. 2) If you're up for it, please add a test. I confess I did not test it. If you don't feel like it's necessary here, that's ok by me. 3) One tweak to the new

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

Subject: [PATCH] aclocal: add m4 search path info to --help Add a short summary to --help of the current paths ... This looks fine to me, FWIW. Please go ahead and commit. By the way, it occurs to me that it might be more maintainable to send proposed patches to bug-automake, even if

Re: [PATCH] Use gender-neutral pronouns in HACKING and t/README

may be interesting for debugging, so that when a user send a verbose - output we don't have to ask him for more details. Display stderr + output we don't have to ask them for more details. Display stderr I'd like to say "when users" here instead of "when a user", to avoid the

Re: [PATCH] configure: handle KCC on case-insensitive filesystems

Subject: [PATCH] configure: handle KCC on case-insensitive filesystems Pushed with doc tweak per Jim. Thanks.

Re: [PATCH] gitignore: update

> +*~ > +.#* Suggest also adding \#*# (emacs autosave files) and .*.sw[op] (vim autosave files). Pushed, thanks.

Re: [PATCH] m4: replace AC_DIAGNOSE with m4_warn

--- a/m4/obsolete.m4 +++ b/m4/obsolete.m4 Pushed, thanks. grep -r shows more occurrences of AC_DIAGNOSE in m4/init.m4 (seems straightforward) and mkdirp.m4, which seems to be a decision that was undone, but I don't have the energy to try to find the discussion now to see how to "adjust

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

> To help ease people into enabling silent rules by default, warn if FWIW, I don't agree with any of these silent-rule patches, for all the reasons Zack explained. They just seem like they are inflicting pain on existing users with no return benefit. -k

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

Please don't *ever* make this change. I agree with Zack, and just for CI purposes; it is simply too big of an incompatibility to inflict at this late date. Mike, thanks for the suggestion, but let's skip this one. --karl P.S. Personally, I am no fan of silent builds. I find that inevitably

Re: [PATCH] dejagnu: add support for silent builds with site.exp

Hi Mike, Subject: [PATCH] dejagnu: add support for silent builds with site.exp I pushed the change. https://sourceware.org/git/?p=binutils-gdb.git;a=summary after you configure+make, you can iterate with just `make site.exp`. I tried, but failed to really test the change. Hope it

Re: [PATCH] dejagnu: add support for silent builds with site.exp

Thanks for the patch, Mike. * lib/am/dejagnu.am (site.exp): Use $(AM_V_GEN) Ok. Can you tell me how to discern that this makes a difference? Is there some test where it can be observed? I've never actually used dejagnu with Automake. and merge all independent shell calls into one. Is

Re: [PATCH] config headers: add support for silent builds

Hi Mike, * lib/am/remake-hdr.am (%STAMP%): Use $(AM_V_at) and $(AM_V_GEN). (%CONFIG_HIN%): Likewise. Looks good to me. I installed it. Thanks! -k

  1   2   >