Possible typo in config.sub

Hi there, my first post to this list. I was browsing config.sub and stumbled on a possible typo. diff --git a/lib/config.sub b/lib/config.sub index 2c6a07ab3..c5d18ce79 100755 --- a/lib/config.sub +++ b/lib/config.sub @@ -980,7 +980,7 @@ case $cpu-$vendor in ;; c90-unknown |

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Thu, 4 Jul 2024 at 22:27, Karl Berry wrote: > slow every bootstrap for us (which we do frequently) to work around a > relatively rare issue. > > Nick's solution of using acinclude.m4 seems ideal. But just in case: I > think you could also avoid the extra libtoolize calls by doing them

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

slow every bootstrap for us (which we do frequently) to work around a relatively rare issue. Nick's solution of using acinclude.m4 seems ideal. But just in case: I think you could also avoid the extra libtoolize calls by doing them only if the automake --version is x.y.9*, i.e., a test

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Wed, 3 Jul 2024 at 19:52, Nick Bowler wrote: > On 2024-07-03 09:37, Dave Hart wrote: > > On Wed, 3 Jul 2024 at 03:49, Dave Hart wrote: > > > It occurs to me we might avoid issues along these lines by having > > > our bootstrap script invoke libtoolize before autoreconf. > [...] > > I tried

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

libtoolize: linking file `sntp/m4/libtool.m4' Indeed, that seems like it should work, because the aclocal invocation from autoreconf is looking into sntp/m4 (and /m4 too) and finds other files there: .. autoreconf: running: aclocal --verbose --verbose -I sntp/m4 -I sntp/libevent/m4 -I

Re: improve display of filesystem timestamp resolution

A physical entity should always be displayed with its unit. Agreed in principle, but sorry, I'm not ready to install this one. Adding a unit to the value and then removing it everywhere the value is used seems error-prone to me. How about just displaying it with the unit (somehow)? Or

Re: improve display of whether sleep supports fractional seconds

checking whether sleep supports fractional seconds... true is inconsistent with the rest of the GNU Build System. Namely, in configure output, results are "yes"/"no", not "true"/"false". The attached patch makes automake consistent with the rest. Thanks Bruno. I applied, plus

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

> But none of this is meant to suggest that there isn't actually some real > change in aclocal behaviour which is causing the results you are seeing. I've failed to find any regression. As I said, if I install 1.16.5 into a test --prefix and run ntp's bootstrap with that prefix, it cannot

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On 2024-07-03 09:37, Dave Hart wrote: > On Wed, 3 Jul 2024 at 03:49, Dave Hart wrote: > > It occurs to me we might avoid issues along these lines by having > > our bootstrap script invoke libtoolize before autoreconf. [...] > I tried this approach and it didn't help. libtoolize seems to be >

Re: [platform-testers] automake-1.16.92 released

On 2024-07-01 10:21, Zack Weinberg wrote: > # clue Make that gen-foo also updated foo.h whenever foo.c is new > foo.h: foo.c > @: > > If I had to guess, I would guess that someone thought Make would be > more likely to skip invoking a shell if the command was actually empty > rather than

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Wed, 3 Jul 2024 at 03:49, Dave Hart wrote: > > It occurs to me we might avoid issues along these lines by having our > bootstrap script invoke libtoolize before autoreconf. Does that sound wise > to the two of you? > I tried this approach and it didn't help. libtoolize seems to be doing

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Wed, 3 Jul 2024 at 00:58, Nick Bowler wrote: > For autoreconf to work with libtool there just needs to be a definition > of LT_INIT available when it runs autoconf for the first time, in order > for the traces to indicate an expansion of LT_INIT. There are a variety > of ways this might

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On 2024-07-02 13:34, Dave Hart wrote: > Thanks for running this down, Karl. I'm happy if you're happy, but I > am left with one question: Why is it installing prerelease automake > in a different prefix for testing hasn't required also installing > libtool to the same prefix (think back to your

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

Hi Dave, Why is it installing prerelease automake in a different prefix for testing hasn't required also installing libtool to the same prefix In general, I think it does. And always has. This is not new behavior, as far as I can see. (think back to your "baffled" comment)? Indeed

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Tue, 2 Jul 2024 at 17:15, Karl Berry wrote: > Hi Dave, > > # wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz > # tar xf *p18-vcs*xz > # cd *vcs > # ./bootstrap > > After more testing, I don't believe it is a regression. If I install > 1.16.5 in its own prefix, say

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

Hi Dave, # wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz # tar xf *p18-vcs*xz # cd *vcs # ./bootstrap After more testing, I don't believe it is a regression. If I install 1.16.5 in its own prefix, say /tmp/am165, the ntp bootstrap fails in the same way:

improve display of whether sleep supports fractional seconds

This configure output checking whether sleep supports fractional seconds... true is inconsistent with the rest of the GNU Build System. Namely, in configure output, results are "yes"/"no", not "true"/"false". The attached patch makes automake consistent with the rest. Verified to pass "make

improve display of filesystem timestamp resolution

Hi, This configure output checking for a BSD-compatible install... /usr/bin/install -c checking whether sleep supports fractional seconds... true checking filesystem timestamp resolution... 2 checking whether build environment is sane... yes ... bugs me, like it would bug every

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

Repro steps Thanks. Evidently something must have changed in automake's libtool support, but looking at the ChangeLog, I don't see it. I will look into it ... --thanks, karl.

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Sun, 30 Jun 2024 at 20:31, Karl Berry wrote: > Hi Dave, > > installed and installing the prerelease version to a prefix earlier on > my > $PATH, not realizing I also needed to install libtool to the same > prefix > > Well, I'm glad that it's apparently not a "real" problem, but I'm

Re: [platform-testers] automake-1.16.92 released

On Sun, Jun 30, 2024, at 4:28 PM, Karl Berry wrote: ... > introspection/%.h: introspection/%.c > $() ... > As an aside, I'm curious as to why the $() is used. It seems > a mysterious way to do nothing. Do you know? I don't know why someone chose to do it this way, but I do know that GCC's

Re: [platform-testers] automake-1.16.92 released

On Sun, Jun 30, 2024 at 10:28 PM Karl Berry wrote: > Hi Frederic, > > Hello, > NetworkManager: > Use of uninitialized value $var in string eq at > /usr/share/automake-1.16/Automake/Variable.pm line 754, line > 1169. > > From the Makefile.am you sent me separately (attached here

bug#71847:

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

Hi Dave, installed and installing the prerelease version to a prefix earlier on my $PATH, not realizing I also needed to install libtool to the same prefix Well, I'm glad that it's apparently not a "real" problem, but I'm rather baffled. When I test an automake pretest, I don't do

Re: [platform-testers] automake-1.16.92 released

Hi Frederic, NetworkManager: Use of uninitialized value $var in string eq at /usr/share/automake-1.16/Automake/Variable.pm line 754, line 1169. >From the Makefile.am you sent me separately (attached here for the record), it seems that is coming from the use of $() in:

Re: bug#71487: automake-1.16.92 released

reopen 71487 thanks Dave Hart writes: > After installing Libtool to the same prefix as the prerelease Automake, the > problem disappeared. I think you might have sent this to the wrong bug report. Bug#71487 is an Emacs bug, see: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71487

Re: automake-1.16.92 released

On Sun, 30 Jun 2024 at 05:03, Nick Bowler wrote: > [...] > > autoreconf decides to run libtoolize based on an m4 trace right after > it runs aclocal, looking for expansion of LT_INIT (or the older > AC_PROG_LIBTOOL). > > This means that for this to work at all: > > (1) a macro definition of

bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

Nick Bowler helped educate me on aclocal and libtool interaction on the Automake mailing list. The reason I was hitting this problem was aclocal was not finding libtool installed to the same prefix as automake. To test the prerelease automake I was leaving the base version of automake installed

Re: automake-1.16.92 released

On 2024-06-29 07:28, Dave Hart wrote: > I'm seeing a regression building ntpd on FreeBSD 12.1 amd64 with > Autoconf 2.71 between Automake 1.16.5 and 1.16.92. I haven't filed a > bug report yet as I'm trying to do my part to characterize it well and > provide an easy reproduction. It may well be

Re: automake-1.16.92 released

On Sat, 29 Jun 2024 at 21:29, Karl Berry wrote: > Indeed. Thank you very much for the report (and the followup). The first > question that comes to mind: are you using the same version of libtool > in the various cases? --thanks again, karl. > Yes, on both systems it's libtool 2.4.6 I saw no

bug#71847: Automake 1.16.90 regression mistakenly "not using Libtool"

I'm seeing a problem building ntpd from a Bitkeeper repo that doesn't occur with a make dist tarball when using Automake 2.71 and Automake 1.16.90 or 1.16.92 that reliably does not occur with Automake 1.16.5. To enable easy reproduction, I've made a tarball of the source from a checkout of NTP

Re: First draft of application to Sovereign Tech Fund

Hi Christoph and all - back on the Sovereign Tech Fund application. Here's my first cut at tweaking the wording. Thanks for doing all this. -k Draft of applications (questions are with > at the left of the line): > I acknowledge: > > All code and documentation to be supported

Re: automake-1.16.92 released

Hi Dave, in case it affects a decision to release 1.17 Indeed. Thank you very much for the report (and the followup). The first question that comes to mind: are you using the same version of libtool in the various cases? --thanks again, karl.

Fwd: Automake 1.16.90 regression mistakenly "not using Libtool"

It seems debbugs.gnu.org is down or running behind, so here's what I've found. Further testing after I composed the report shows the Automake 1.16i prerelease also suffers the problem. -- Forwarded message - From: Dave Hart Date: Sat, 29 Jun 2024 at 17:18 Subject: Automake

Re: automake-1.16.92 released

I'm seeing a regression building ntpd on FreeBSD 12.1 amd64 with Autoconf 2.71 between Automake 1.16.5 and 1.16.92. I haven't filed a bug report yet as I'm trying to do my part to characterize it well and provide an easy reproduction. It may well be a bug in our use of Automake, in which case I

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On Sun, Jun 23, 2024, at 10:23 PM, Zack Weinberg wrote: > I'm thinking of making AC_RUN_LOG, which has existed forever but is > undocumented, an official documented macro under the new name > AC_LOG_CMD. I'm renaming it because I also want to add AC_LOG_FILE, a > generalization of

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

Subject: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE. FWIW, it sounds good to me. To my mind, logging is one of the most important features of autoconf, so I'm all for macros to support it further. --thanks, karl.

Re: [platform-testers] automake-1.16.92 released

I ran a mass rebuild on Fedora for packages that depend on automake with this version. Thank you!! Out of 1330 packages built, I found the following failures. Could be a lot worse! NetworkManager x2gokdrive xorg-x11-server Use of uninitialized value $var in string

Re: [platform-testers] automake-1.16.92 released

Hello, I ran a mass rebuild on Fedora for packages that depend on automake with this version. Out of 1330 packages built, I found the following failures. NetworkManager: Use of uninitialized value $var in string eq at /usr/share/automake-1.16/Automake/Variable.pm line 754, line 1169. x2gokdrive

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On 2024-06-24 10:04, Zack Weinberg wrote: > On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote: >> I think at the same time it would be worth documenting the AS_LINENO >> functionality, which is the main internal functionality of these >> macros that (unless you just goes ahead and use it)

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote: > On 2024-06-23 22:23, Zack Weinberg wrote: >> I'm thinking of making AC_RUN_LOG, which has existed forever but is >> undocumented, an official documented macro ... > > Yes, please! > > I will note that Autoconf has a lot of "run and log a

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

On 2024-06-23 22:23, Zack Weinberg wrote: > I'm thinking of making AC_RUN_LOG, which has existed forever but is > undocumented, an official documented macro ... Yes, please! I will note that Autoconf has a lot of "run and log a command" internal macros with various comments of the form "doesn't

RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

I'm thinking of making AC_RUN_LOG, which has existed forever but is undocumented, an official documented macro under the new name AC_LOG_CMD. I'm renaming it because I also want to add AC_LOG_FILE, a generalization of _AC_MSG_LOG_CONFTEST. These are handy any time you want to record details of

[bug#71672] [PATCH] python: Prefer python3 over python

zw> Add these three macros to Autoconf proper: ... Automake's python.m4 should also define these if they are not already defined. Then, we split AM_PATH_PYTHON ... Thanks Zack. It all sounds good to me. definitely do this early rather than late in an automake release

[bug#71672] [PATCH] python: Prefer python3 over python

Zack Weinberg wrote: > Automake's python.m4 should also define these if they are not already defined. > Then, we split AM_PATH_PYTHON into the part that sets PYTHON, which is > implemented > in terms of the above macros (but still looks for both 2 and 3) and the part > that > does all the rest

[bug#71672] [PATCH] python: Prefer python3 over python

Here's what I think might be useful: Add these three macros to Autoconf proper: # AC_PYTHON_VERSION_RANGE_IFELSE([PROG], [MIN-VERSION], [MAX-VERSION = next-major], #[ACTION-IF-TRUE], [ACTION-IF-FALSE]) # - #

Re: [platform-testers] automake-1.16.92 released

Hi Jim, > > I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, > > and built that on various platforms (from Alpine Linux to MSVC) [1]. > > Everything OK; all tests passed. > > > > Obviously this tests only a small part of the Automake functionality, > > namely the part of "just

Re: [platform-testers] automake-1.16.92 released

On Fri, Jun 21, 2024, 16:46 Bruno Haible wrote: > Jim Meyering wrote: > > We're particularly interested in bugs or regressions in the actual > > Automake functionality. > > I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, > and built that on various platforms (from Alpine

[bug#71672] [PATCH] python: Prefer python3 over python

Or maybe AM_PYTHON3_PATH which requires Python3 so that the interface of the original macro isn't changed. My idea for having a separate options command was for the future: who knows what incompatibilities python will create in the future. Other options besides p3 vs p2 might be needed.

[bug#71672] [PATCH] python: Prefer python3 over python

Hi Karl, Karl Berry wrote: > Yes ... but I feel strongly that we should try very hard not to break > existing configure setups. Reasonable goal. > It occurs to me that we could allow maintainers to specify p3-searching > options in their configure.ac, like > >

Re: [platform-testers] automake-1.16.92 released

Jim Meyering wrote: > We're particularly interested in bugs or regressions in the actual > Automake functionality. I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92, and built that on various platforms (from Alpine Linux to MSVC) [1]. Everything OK; all tests passed. Obviously

[bug#71672] [PATCH] python: Prefer python3 over python

I thought the intention was to prioritize python 3.X which would cause problems using "python" first. Yes ... but I feel strongly that we should try very hard not to break existing configure setups. It occurs to me that we could allow maintainers to specify p3-searching options in their

automake-1.16.92 released

[Thanks to Karl Berry for doing so much of work again, preparing for this release and even writing most of the following. ] We are pleased to announce the GNU Automake 1.16.92 test release. This is a release candidate for the upcoming automake-1.17. It mostly attempts to eliminate a delay in

[bug#71672] [PATCH] python: Prefer python3 over python

Karl Berry wrote: > I can imagine preferring "python3" to "python" in the future, but this > seems like too big of a change to make at the very end (I hope) of the > pretest cycle. I think it would be better to make it well in advance of > the next release and try to garner feedback on the

[bug#71672] [PATCH] python: Prefer python3 over python

Collin, Zack - > Shouldn't AM_PATH_PYTHON check for the python3 command before python? Yes it should. That seems like a huge change to make. I understand the reasoning, given the world of Python, but the goal of "don't break existing projects" argues against it. Note that PEP 394

Re: branch master updated: lib scripts: add "(GNU Automake)" to --version output, etc.

Why two blank lines, not just one as for the other scripts? Slip of the editor. Will fix. Thanks for the sharp eyes. -k

Re: branch master updated: lib scripts: add "(GNU Automake)" to --version output, etc.

Re : Thanks for having done this, Karl. It fixes the issue you reported to bug-gnulib (regarding 'ar-lib'). But in lib/test-driver: > @@ -50,6 +50,11 @@ Usage: > > The '--test-name', '--log-file' and '--trs-file'

[bug#71672] [PATCH] python: Prefer python3 over python

On Thu, Jun 20, 2024, at 5:50 AM, Collin Funk wrote: > Shouldn't AM_PATH_PYTHON check for the python3 command before python? Yes it should. > The full recommendation of how these should be setup is in PEP 394 Note that PEP 394 is dangerously incorrect on one point: a system where

[bug#71672] [PATCH] python: Prefer python3 over python

Hi, Shouldn't AM_PATH_PYTHON check for the python3 command before python? The full recommendation of how these should be setup is in PEP 394 [1]. On modern systems I don't think it should matter. On Fedora 40: $ command -v python /usr/bin/python $ command -v python3

Re: 1.16.90 regression: configure now takes 7 seconds to start

have to say --enable-maintainer-mode Personally I agree with you, in theory, but I think it is too big of a change to make. As I understand it. GNU package authors have their source repos and have never had to say --enable-maintainer-mode before to get their Makefiles etc. rebuilt. I don't

[bug#71652] optimizing the sleep in Automake's sanity.m4

I'd like to have further discussion about this ongoing subject here, for the sake of future trackability. So far as I can see, we've currently got Bruno's patch#2 from https://lists.gnu.org/archive/html/automake/2024-06/msg00055.html (attached here)

Re: 1.16.90 regression: configure now takes 7 seconds to start

Bruno Haible wrote: Jacob Bachmeyer wrote: under what conditions can "checking that generated files are newer than configure" actually fail? I mentioned two such conditions in [1]: - Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours of skew.) - If the

Re: 1.16.90 regression: configure now takes 7 seconds to start

Zack Weinberg wrote: On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote: [...] Wait... all of configure's non-system dependencies are in the release tarball and presumably (if "make dist" worked correctly) backdated older than configure when the tarball is unpacked. In my

bug#71633:

Oops, this debbugs report was created when I replied to the original message, before automake-patches was connected to debbugs. https://lists.gnu.org/archive/html/automake-patches/2022-01/msg00029.html Closing ...

[bug#71633] [PATCH v2] aclocal: add --aclocal-path option to override $ACLOCAL_PATH

Date: Mon, 24 Jan 2022 03:33:51 -0500 From: Mike Frysinger To: automake-patches@gnu.org Subject: [PATCH v2] aclocal: add --aclocal-path option to override $ACLOCAL_PATH The $ACLOCAL_PATH env var is useful, but setting environment vars is a bit clunky. Add an

Re: 1.16.90 regression: configure now takes 7 seconds to start

On Tue, Jun 18, 2024, at 10:19 AM, Bruno Haible wrote: > Zack Weinberg wrote: >> Literally as I type this I am >> watching gettext 0.22 run its ridiculous number of configure scripts a >> second time from inside `make`. > > You can run into such problems: > - if you take a tarball of a git

Re: 1.16.90 regression: configure now takes 7 seconds to start

Zack Weinberg wrote: > Literally as I type this I am > watching gettext 0.22 run its ridiculous number of configure scripts a > second time from inside `make`. I'm glad that you didn't write "its ridiculously large configure scripts" :-) Jokes aside, it's highly unusual that 'configure' runs

Re: 1.16.90 regression: configure now takes 7 seconds to start

On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote: >> >> I regret to say, yes, there are. For example, this can happen with >> NFS if there are multiple clients updating the same files and they >> don't all

Re: Bug Resilience Program of German Sovereign Tech Fund

Hi Karl, I think this not a problem. Citing their criteria [1]: > FOSS: all code and documentation to be supported must > be licensed such that it may be freely reusable, > changeable, and redistributable. OSI-approved or > FSF Free/Libre licenses are acceptable for code. Nevertheless, we

Re: 1.16.90 regression: configure now takes 7 seconds to start

Jacob Bachmeyer wrote: > under what conditions can "checking that > generated files are newer than configure" actually fail? I mentioned two such conditions in [1]: - Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours of skew.) - If the configure file was created less

Re: 1.16.90 regression: configure now takes 7 seconds to start

Zack Weinberg wrote: On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote: ... Don't have enough brain right now to comment on any of the rest of your suggestions, but: once conftest.file is newer than configure, surely config.status, which is produced after all tests are run, /must/

Re: 1.16.90 regression: configure now takes 7 seconds to start

On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote: ... Don't have enough brain right now to comment on any of the rest of your suggestions, but: >once conftest.file is newer than configure, surely > config.status, which is produced after all tests are run, /must/ also be > newer than

Re: 1.16.90 regression: configure now takes 7 seconds to start

Nick Bowler wrote: On 2024-06-16 21:35, Jacob Bachmeyer wrote: I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST to touch config.status if neccessary, instead of trying to decide whether to sleep before writing config.status. If the problem is simply that we

Re: 1.16.90 regression: configure now takes 7 seconds to start

Nick Bowler wrote: > while ${MAKE-make} -f conftest.mk >/dev/null 2>&1 > do > touch config.status > done]) I would use 'echo >> config.status' instead of 'touch config.status'. Rationale: When the user is working in an NFS file system mount, and there is a clock skew between the

Re: 1.16.90 regression: configure now takes 7 seconds to start

Karl Berry wrote: >This patch is conservative; IMO safe for a 1.17 release. > > I like the idea of a conservative patch, for sure. I see that what > you're doing here is simply omitting the 1 second trial for the sake of > saving that time, in exchange for accepting a 2s delay in the Automake

Re: 1.16.90 regression: configure now takes 7 seconds to start

Let's look at the history. Thanks very much for all that research and explanations, Bruno. Likewise, Jacob. https://lists.gnu.org/archive/html/bug-automake/2010-10/msg0.html Aha, the explanation for some of the $sleep commands scattered throughout the Automake tests! I had no idea.

Re: 1.16.90 regression: configure now takes 7 seconds to start

Nick> AC_CONFIG_COMMANDS_POST([cat >conftest.mk <<'EOF' configure: config.status false EOF while ${MAKE-make} -f conftest.mk >/dev/null 2>&1 do touch config.status done]) One missing element is that there is no limit, which would be a

bug#71421: system info in test-suite.log

Karl Berry wrote: > Thanks Collin. I installed it (with minor wording tweaks). Looks good, thanks. > I had thought the extra space was useful rather than confusing, > indicating that a word had been omitted from the output. But I'm fine > with leaving it out. -k I didn't mind it much but I do

bug#71421: system info in test-suite.log

I've attached a patch that I think handles that Thanks Collin. I installed it (with minor wording tweaks). and the extra space you mentioned. I had thought the extra space was useful rather than confusing, indicating that a word had been omitted from the output. But I'm fine with

bug#71596:

Re: Bug Resilience Program of German Sovereign Tech Fund

Christoph - I had one more thought about the tech fund: Automake is copyright FSF. So Neighorhoodie is going to need to sign a disclaimer or (preferably) assignment for any patches to be usable. Is there precedent in the fund for doing that? --thanks, karl.

bug#71422: no easy way to generate a test-suite.log without skipped tests

Here is a patch that allows the package maintainer to eliminate the SKIPped test logs, thus making test-suite.log more useful: either by running make check IGNORE_SKIPPED_LOGS=1 or by defining in the Makefile (or Makefile.am): IGNORE_SKIPPED_LOGS = 1 Thanks Bruno. I

bug#71421: system info in test-suite.log

Hi Bruno, You said: > The problem with this is that > - It's not immediately clear to everyone what this information is. > - It can get in the way, for example when I want to search for "Linux" > among the test logs: > grep '^Linux' test-suite.log > > I would therefore suggest to

Re: 1.16.90 regression: configure now takes 7 seconds to start

On 2024-06-16 21:35, Jacob Bachmeyer wrote: > I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST > to touch config.status if neccessary, instead of trying to decide > whether to sleep before writing config.status. If the problem is simply that we want to avoid the

Re: use of make in AM_SANITY_CHECK

Karl Berry wrote: make(1) in AM_SANITY_CHECK seems to be a logic error, since the user may want to build with a different $MAKE, You're right. Crap. It never ends. In practice it probably doesn't matter, though. Although in theory one can imagine that "make" succeeds while $MAKE

Re: 1.16.90 regression: configure now takes 7 seconds to start

Karl Berry wrote: Find here attached a revised proposed patch. Ok on the reorg, but sorry, I remain confused. This whole thing started with Mike Vapier's change in Feb 2022 (commit 720a11531): https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html As I read it now, his

Re: 1.16.90 regression: configure now takes 7 seconds to start

Two days ago, I wrote: > Find here attached a revised proposed patch. But I had missed the parallel 'sleep $am_cv_filesystem_timestamp_resolution'. Sorry, I have to withdraw that patch as well. Now, with the big picture that I gained by replying to Karl's questions, here are two alternative,

Re: 1.16.90 regression: configure now takes 7 seconds to start

Hi Karl, > I understand that equal timestamps are considered up to date Yes, except for old HP-UX 'make', which no one uses any more, all 'make' programs consider equal timestamps as "up-to-date". > Ok, but > then why is configure generating config.status/etc. such a special case > that it

[bug#71534] [PATCH] aclocal: support ACLOCAL_PATH correctly on OS/2

Karl Berry wrote: > - foreach my $dir (reverse split /:/, $ENV{"ACLOCAL_PATH"}) > + my $sep = $^O eq 'os2' ? ';' : ':'; > + foreach my $dir (reverse split /$sep/, $ENV{"ACLOCAL_PATH"}) > > Thanks for the report. I added a check for Windows and committed it. > --best, karl. >

Re: use of make in AM_SANITY_CHECK (was: improved timestamp resolution test)

make(1) in AM_SANITY_CHECK seems to be a logic error, since the user may want to build with a different $MAKE, You're right. Crap. It never ends. In practice it probably doesn't matter, though. Although in theory one can imagine that "make" succeeds while $MAKE fails, resulting in a

[bug#71425] test: Accommodate C23 compilers.

Hi Collin, In the yacc test I see warnings like this: main.c:4:10: error: implicit declaration of function 'yyparse' [-Wimplicit-function-declaration] 4 | return yyparse (); | ^~~ and some for yylex which is declared, but with an empty parameter

Re: 1.16.90 regression: configure now takes 7 seconds to start

Find here attached a revised proposed patch. Ok on the reorg, but sorry, I remain confused. This whole thing started with Mike Vapier's change in Feb 2022 (commit 720a11531): https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html As I read it now, his goal was to speed up

bug#71596: instdir-ltlib test and libtool -rpath failure

When Paul fixed typos in various files a few days ago: commit 1d35638b23e95fe6f41c828a3442f6d7f242f4c4 Author: Paul Eggert AuthorDate: Fri Jun 7 08:41:45 2024 -0700 maint: spelling and whitespace fixes He noted: * t/instdir-ltlib.sh: Fix misspellings of macro names.

[bug#71534] [PATCH] aclocal: support ACLOCAL_PATH correctly on OS/2

- foreach my $dir (reverse split /:/, $ENV{"ACLOCAL_PATH"}) + my $sep = $^O eq 'os2' ? ';' : ':'; + foreach my $dir (reverse split /$sep/, $ENV{"ACLOCAL_PATH"}) Thanks for the report. I added a check for Windows and committed it. --best, karl.

bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.

Hi Yves - back in 2017 you sent a patch to sort keys in automake: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629 Attached is a patch that I believe fixes any remaining uses of unsorted keys. I've now applied this, with the exception of a) the cases that had already been done in

Re: use of make in AM_SANITY_CHECK (was: improved timestamp resolution test)

Karl Berry wrote: Jacob, [*sigh*] You said it. About this whole thing. I rather wish this bright idea had never come to pass. It has delayed the release by months. Oh well. Still, could we use make(1) for *all* of the testing and not use `ls -t` I guess it is technically possible,

Re: Bug Resilience Program of German Sovereign Tech Fund

Hi Christoph, All Automake release announcements since 2.13 warn about future Automake 2.0 incompatibilities. I moved that noisy warning from the top of NEWS into a separate NEWS-2.0 file a couple of releases ago. At the beginning there is a meeting between you (maybe more people,

Re: Bug Resilience Program of German Sovereign Tech Fund

Hello Karl, don't get me wrong. I think GNU Autotools will not vanish and projects will rely on it for at least another decade. I am thankful for your work and we need to keep this project alive. That is the reason I am proposing to apply for contributions. Still, I think many projects do not

Re: End of life dates vs regression test matrix

On 2024-06-14 10:09, Dan Kegel wrote: > Oh, ok, perhaps I was confused by the note in automake 1.13.1's NEWS file > (iirc), which said > > Support for IRIX and the SGI C/C++ compilers will be removed in > Automake 1.14: they have seen their last release in 2006, and SGI > is expected to

Re: End of life dates vs regression test matrix

Oh, ok, perhaps I was confused by the note in automake 1.13.1's NEWS file (iirc), which said Support for IRIX and the SGI C/C++ compilers will be removed in Automake 1.14: they have seen their last release in 2006, and SGI is expected to retire support from them in December 2013 Did that not

  1   2   3   4   5   6   7   8   9   10   >