Re: Is it possible to extend the built-in dependency tracking?

Hi Nick - wow, thank you very much for that detailed reply! I had no idea ... it works in a very simple way I'm not sure I'd call anything about the dependency tracking "very simple" :). and it is relatively straightforward to extend it. Thanks again. I think I'll link to your messa

Re: Is it possible to extend the built-in dependency tracking?

Hi Tomas - thanks for writing. As far as I know, there is nothing in Automake to support extension of dependency tracking by users to new languages. Unfortunately. If it's possible for you to add dependency tracking for Guile into Automake, that would be welcome. You might like to peruse the seco

Re: TAP Directives for XPASS and XFAIL tests with lib/tap-driver.sh

See https://testanything.org/tap-specification.html under "TODO tests". Thanks Russ. But what Soham is describing is not at all a "TODO" item as described there. I'm far from familiar with the ins and outs of TAP and its conventional usage, but it seems like a matter of semantics to me. It ca

automake-1.18.1 released [stable]

people committed changes to this release: Bruno Haible (2) Collin Funk (1) Karl Berry (7) Thanks to everyone who has contributed. Special thanks to Frederic Berat and Santiago Vila for their bug reports and discussion of mdate-sh. Karl [on behalf of the automake developers

Re: Automake 1.18 regression (?)

Hi Santiago, The Debian build of m4 version 1.4.19 dropped UPDATED from doc/m4.texi because it was using autoreconf, Aha! A similar problem was reported when the bootstrap script was run unnecessarily. This is recommended by some people in Debian but I'm skeptical that it's a go

Re: Automake 1.18 regression (?)

jcb> Could the right answer be to limit the effect of SOURCE_DATE_EPOCH to timestamps that will appear in built files? I'm afraid I'm not sure what you mean, Jacob. At any rate, before flailing around further, I'd like to understand why the Debian build had problems with the original mdat

Re: Automake 1.18 regression (?)

Hi Frederic, So, I re-built Fedora packages and found that the patch I mentioned above is actually creating a new dependency on packages that use automake: It's so frustrating. The original tarball is (presumably) entirely correct but the playing with pretend mtimes causes timestamp prob

Re: Automake 1.18 regression (?)

Hi Frederic and all - I pushed the following tweaks to a few tests. With these changes, I was able to run make distcheck with SOURCE_DATE_EPOCH=86402 (among other values). Hope it suffices .. --thanks, karl. (And thanks Carlos for the info.)

Re: Automake 1.18 regression (?)

Hi Frederic - it would be better to send failures to bug-automake, so they get bug numbers. But no big deal. I'm facing a strange regression between 1.17.92 and 1.18 when rebuilding Automake: FAIL: t/txinfo-vtexi4 Are you setting SOURCE_DATE_EPOCH in the failing build and if so, to wh

Re: automake-1.18 released [stable] [signatures]

Hi Valentin, It seems that the key used to sign the archive is no longer the one from the automake group. I signed it. I'm one of the listed admins of the automake group on savannah (https://savannah.gnu.org/projects/automake/), so I don't know what you mean by "from the automake group".

Re: Makeinfo required to build Automake 1.18

Hi Gavin, https://lists.gnu.org/archive/html/bug-texinfo/2022-05/msg0.html I wrote at the time (in a private email): > Yes, I am still opposed. I believe it is wrong to include it in the > distribution as it can delete or overwrite files from the distribution, > with no w

Re: Makeinfo required to build Automake 1.18

ps> I am not familiar with automake's development model, but in general for all GNU packages, at least: It's the same for Automake. (Not that I wrote any of Automake's bootstrap script -- I don't believe it's changed in many years.) Cf> running ./bootstrap (or autoreconf -fvi manually

Re: Makeinfo required to build Automake 1.18

Hi Christoph, Note, that the issue arises when `make install` is called. tar xf automake-1.18.tar.xz && configure --prefix=/tmp/a18 && make install doesn't run makeinfo for me either. Or make install DESTDIR=/tmp/adest. I can only surmise that something in your process before the make insta

Re: Makeinfo required to build Automake 1.18

Hi Christoph, I wanted to update the openSuse package for Automake to 1.18. But I get an error that makeinfo is not found. Past releases did no require makeinfo. Is this an oversight? Argh. Certainly makeinfo is not supposed to be required. But when I unpack it and run configure an

automake-1.18 released [stable]

who has contributed! The following people contributed changes to this release: Bogdan (1) Bruno Haible (4) Collin Funk (3) Eric Gallager (1) Gavin Smith (1) Jim Meyering (1) Jose Marchesi (4) Kamila Szewczyk (1) Karl Berry (33) Paul Eggert (3) Reuben Thomas (2) Richard Hansen

Re: m4p: an implementation of GNU m4 in Python

Hi Nikolaos, To: , Subject: m4p: an implementation of GNU m4 in Python An impressive project, but I think you should tell autoc...@gnu.org, not automake@gnu.org. Although there are Autoconf macros and a little other m4 stuff in Automake, it's minor compared to Autoconf.

automake-1.17.92 pretest released [alpha]

n the documentation. There have been 54 commits by 11 people in the 39 weeks since 1.17. Bogdan (1) Bruno Haible (3) Collin Funk (2) Eric Gallager (1) Gavin Smith (1) Jim Meyering (1) Jose Marchesi (2) Kamila Szewczyk (1) Karl Berry (24) Paul Eggert (3) Richard Hansen (15) Thanks to eve

Re: automake-1.17.90 pretest released [alpha]

rom: Nick Bowler To: Ross Burton Cc: Karl Berry , "automake@gnu.org" Subject: Re: automake-1.17.90 pretest released [alpha] On Thu, Feb 27, 2025 at 06:23:42PM +, Ross Burton wrote: .. > >| configure:2612: error: possibly undefined macro: AM_RUN_LOG .. > A leaner test

Re: automake-1.17.90 pretest released [alpha]

In a clean build with 1.17, autom4te.cache/traces.0 says: ... But in a build with 1.17.90 that has previously been configured with 1.17: m4_if([$1], [1.17], [], Ross, do you have a $HOME/.config.site or other config.site file that might somehow be causing the different results? See

Re: automake-1.17.90 pretest released [alpha]

In a clean build with 1.17, autom4te.cache/traces.0 says: ... But in a build with 1.17.90 that has previously been configured with 1.17: m4_if([$1], [1.17], [], Unfortunately I have basically zero understanding of autom4te. (It's part of autoconf.) So some state from the old b

Re: automake-1.17.90 pretest released [alpha]

Resending another message from Ross with interesting info, my reply follows. -k Date: Thu, 27 Feb 2025 18:30:43 + From: Ross Burton To: Karl Berry Subject: Re: automake-1.17.90 pretest released [alpha] I need to eat but one quick datapoint from doing a three-way comparison with meld. In

Re: automake-1.17.90 pretest released [alpha]

Hi Ross, | configure:2612: error: possibly undefined macro: AM_RUN_LOG I've been unable to reproduce this, even though you get the error pervasively :(. I tried cloning your repo: git clone git://git.yoctoproject.org/matchbox-sato PATH=/path/to/pretest/bin:$PATH sh autogen.sh grep AM_RUN_LO

Re: Avoiding the sleep(1) in configure.ac

Hi Ross, In that block, set am_build_env_is_sane to ``unknown'' if it isn't already set, and do the touch/sleep loop if it is set to unknown. For the default case the behaviour is unchanged but this will allow anyone who wants to gain a second of walltime to set am_build_env_is

Re: automake-1.17.90 pretest released [alpha]

Is the plan for the next automake release to be automake 1.18? Yes. Since there are new features. --thanks, karl.

automake-1.17.90 pretest released [alpha]

Jose Marchesi (1) Kamila Szewczyk (1) Karl Berry (19) Paul Eggert (3) Richard Hansen (14) Thanks to everyone who has contributed! Karl [on behalf of the automake maintainers] == Detailed download/signature information fo

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

PERL5OPT= $MAKE check || st=$? Done, thanks. Unsetting PERL5OPT before the test runs automake defeats the purpose of using PERL5OPT here, which is that warnings raised while running Automake should be fatal. I know, but it seemed so minor to worry about it for this one test amo

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

Unsetting it in the shell test driver could work, Yep. That's what I had in mind, sorry I wasn't clear. to the line that actually executes the Perl script The t/parallel-tests-log-compiler-example.sh test (copied below) is testing Automake tests, so the script is not invoked directly, b

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

Hi Jacob, If a plain "use warnings;" in a script overrides setting PERL5OPT=-Mwarnings=FATAL,all in the environment, Fortunately, it was my mistake. I got confused in the testing I was doing. use warnings; in a script does not override that PERL5OPT setting. I'll fix the intentional w

Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c"

https://review.openocd.org/c/openocd/+/8600 If you check out OpenOCD before that commit Not sure I'm up for debugging your source tree, but to take a first look, can you tell me what command(s) to run to get this checkout please? I have no idea, sorry. It didn't happen always That's

Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c"

Hi, Subject: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c" Looking again at your message from last November (sorry) https://lists.gnu.org/archive/html/automake/2024-11/msg0.html I am puzzled as to what's going on. Maybe you can provide a runnable ex

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

citly use warnings so that PERL5OPT=-Mwarnings=FATAL,all +# in the environment won't be a fatal error. See ../HACKING. +echo 'use warnings; my $a =+ 2; exit (0);' > foo.pl echo 'import sys; sys.exit(0);' > bar.py : > baz Running command: git commit \-q \-F \.\/vc\-dwim\-log\-3EzXBh \-\-author\=Karl\ Berry\ \ \-\- ChangeLog + set +x compile finished at Tue Feb 4 08:22:26 2025

version numbers and new features

On another front ... Automake's HACKING file says that "micro releases", e.g., 1.17.1, should not add any new features. Does anyone know if there is a technical reason for this? I just added Jose's Algol 68 support, but our next release feels a lot more like 1.17.1 to me than 1.18. I think the rul

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

I have to admit I don't much like any method Jacob mentioned, or anything else I can think of (sed ...) to munge core source files. I don't know about the past, but I've never knowingly ignored a Perl warning that's been reported or that I've seen. Going to these lengths to have fatal warnings in

Re: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

00 100644 --- a/lib/Automake/RuleDef.pm +++ b/lib/Automake/RuleDef.pm @@ -15,10 +15,7 @@ package Automake::RuleDef; -use 5.006; -use strict; -use warnings FATAL => 'all'; - +use 5.006; use strict; use warnings; use Carp; use Exporter; diff --git a/lib/Automake/VarDef.pm b/lib/Auto

RE: automake-1.17 fails with latest Perl (5.41.8) - Possible precedence problem between ! and numeric eq (==)

it> Here's the thread where I have reported the issue to the perl community https://github.com/Perl/perl5/issues/22954#issuecomment-2622966302 I hope they don't persist in warning about this common use of the !! idiom in their next stable release. Re the notes about the Automake code, I d

Re: "make dist" bug with "EXTRA_DIST += dirname" and built-in rule for "dirname.c"

Hi - thanks for the report. $(ANGIE_FILES) refers to source subdirectory "src/jtag/drivers/angie/", but next to it there is a source file called "src/jtag/drivers/angie.c". I don't think Automake currently tries to consider the values of EXTRA_DIST, just copies them. So it's probably

Re: Do not require ABOUT-NLS in source directory

automake: require ABOUT-NLS only at gnits Thanks Gavin (and Bruno). I pushed the change to automake. -k

Re: Bug Resilience Program of German Sovereign Tech Fund

I received an answer from the German Sovereign Tech Fund regarding our application for their bug resilience program. Automake is on the waiting list for next year. Thanks Christoph!

Re: First draft of application to Sovereign Tech Fund

Hi Detlef - I think Christoph has already submitted the application to the fund, in somewhat different form than the one you commented on. There are some subsequent msgs between he and I on the list. (In short, I basically agree[d] with all your comments. We probably didn't get everything right fo

Re: First draft of application to Sovereign Tech Fund

I added your paragraph to the section "Describe why your project needs those services?" Sounds good. Can I submit the application? Yes. Time to give it a try. Thanks for the initiative. --best, karl.

Re: First draft of application to Sovereign Tech Fund

1) It looks to me like GCC uses autoconf but not automake. Maybe change the answer to: > Where is your open source technology project being > used (describe all user bases)? GNU Automake is used by a very large number of GNU and non-GNU packages. Here are just a couple of examples: GNU coreutils

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 having

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 "qu

Re: [platform-testers] automake-1.16.92 released

ts.gnu.org/archive/html/automake/2024-06/msg00085.html +# (The actual purpose of the "$()" is unclear.) + +. test-init.sh + +cat > Makefile.am << 'END' +x: + $() +END + +$ACLOCAL +$AUTOMAKE + +: Running command: git commit \-q \-F \.\/vc\-dwim\-log\-wBh6_U \-\-auth

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 mu

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.

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 e

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

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

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

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.

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 fals

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 ot

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

Hi Christoph, I advice everybody so seek alternatives. I'm sorry to hear it. My own personal experience (with my sysadmin hat on) is that all alternatives have been inferior. Which is, ultimately, why I choose to spend my time here. I would love to see any minor improvement, as the docum

Re: improved timestamp resolution test (was: 1.16.90 regression: configure now takes 7 seconds to start)

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, but I somehow feel dou

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

Sorry, but I don't really understand your patch. With it, it would seem that _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is only called if the build environment is not "sane", i.e., a created file is not newer than configure. Is that right? (That embedded shell construct is hard to grok.) is in _AM_FI

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

Does BSD ls(1) support "--time=ctime --time-style=full-iso"? BSD ls does not support any --longopts. Looking at the man page, I don't see "millisecond" or "subsecond" etc. mentioned, though I could easily be missing it. E.g., https://man.freebsd.org/cgi/man.cgi?ls Even if there is such an

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

It should save 6 seconds. Because it goes like this: - Test whether 0.01 sec works. - Test whether 0.1 sec works. - If not, set the variable to 2, because that's the worst case and it *must* work. At which places will then a 'sleep 2' be done where (if not VFAT) a

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

> Any other ideas? A horrible one: :) split the test so it can be performed in parallel with others -- upper half starts the sleep in the background, lower half waits for it to complete. No thanks. I can't even begin to imagine the portability and edge case problems that w

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

Maybe this is a silly question, but, is there a reason why this test needs to be performed in every single package that uses Automake? I was under the impression that the purpose of this test was merely to speed up running Automake's own test suite. There are other packages that h

Re: Bug Resilience Program of German Sovereign Tech Fund

Hi Christoph, https://www.sovereigntechfund.de/programs/bug-resilience Thanks for bringing this up. > Our partner 'Neighbourhoodie Software' provides a variety > of types of contributions to participating projects to > address known issues, If that means providing patches fo

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

bh> Seen e.g. on NetBSD 10.0. Which doesn't support subsecond mtimes? jb> Maybe the best answer is to test for subsecond timestamp granularity first, and then only do the slow test to distinguish between 1-second and 2-second granularity if the subsecond granularity test gives

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

Date: Sat, 08 Jun 2024 00:27:39 +0200 From: Bruno Haible To: Subject: 1.16.90 regression: configure now takes 7 seconds to start [I'm writing to automake@gnu.org because bug-autom...@gnu.org appears to be equivalent to /dev/null: [...] It seems this has been fixed, what

Re: automake 1.17 release plan?

Hi Christoph, end of 2023 you shared the news that automake release 1.17 could happen Indeed. Unfortunately since then I have had to attend to other priority projects, and there's no one else driving automake. I hope to be able to spend some time on automake again soon to bring the release t

Re: How to force libtool to use CXX mode?

Automake does have a critical bug in that for a target which only optionally has C++ sources, that target is always linked using C++. So it should only use C++ if the "option" is selected? Can you provide a test tree? Without this issue, the trick of including an empty optional C++

Re: How to force libtool to use CXX mode?

convince Automake to force libtool to link using the C++ compiler When there are no C++ sources? Why? Just trying to understand ... I'm sorry Bob, but I just don't know. Maybe the just-released libtool-2.5.0 alpha offers some new help? If there is some bug in or feature for Automake that wo

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

I'm also wondering whether the GNU system should recommend using zstd instead of or in addition to xz for compression purposes. I'm not sure GNU explicitly recommends anything. Although the tarball examples in standards.texi and maintain.texi all use gz, I don't think even gz is explicitly

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

`distcheck` target's prominence to recommend it in the "Standard Targets for All Users" section of the GCS? Replying as an Automake developer, I have nothing against it in principle, but it's clearly up to the GNU coding standards maintainers. As far as I know, that's still rms (for anyth

Re: C library promoted to C++ linkage due to optional C++ source module

Hi Bob, It is my opinion that if a library or program is linked with C++ libraries (and especially if it is a static build!) that it should be linked using the C++ linker. Likewise, if a library or program does not depend on, or contain any C++ code, it should be linked wi

purpose of line ".. contents:: :depth: 2" in test-suite.log?

Does anyone know what this line in automake-generated test-suite.log files is used by or intended for? . contents:: :depth: 2 It appears to be machine-parsable, but I can't find any reference to it in the code or the doc. There doesn't seem to be anything that outputs :depth: 3 (or anything else)

automake-1.16j pretest available: please test

The GNU Automake 1.16j development snapshot is now available. Download here: https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.xz https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.gz We intend for automake 1.17 to be released soon, essentially with only bug fixes for whatever is found

Re: Typo in NEWS section "New in 1.17" and "New in 1.15"

While reading the announcement for 1.16i, I found a typo in the NEWS file "New in 1.17" section. I have also accidentally found a typo in the "New in 1.15" section, Thanks x 2, Hans. Applied. which might need a line rewrap after the fix. Nah, it's ok. I have not system

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

Hi Zack, *automake* can exit with code 63 under some circumstances, but it really looks like aclocal never will. Agreed. I searched for "63" in automake distributions back to 1.11.3, as well as the current sources, and no trace of any 63's in aclocal, only in automake. Thus I suspect that

automake-1.16i pretest available: please test

We are pleased to announce the GNU Automake 1.16i development snapshot. We intend for automake 1.17 to be released soon, essentially with only bug fixes for whatever is found in this pretest. So please do test if at all possible. It's our primary goal to preserve compatibility. If this release of

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

Features: subsecond-timestamps Sounds good to me, FWIW. Thanks to all. -k

Re: rhel8 test failure confirmation?

I thought we were talking about automake's testsuite probing the behavior of *autom4te* Yes, exactly. Sorry for the confusion. $ ./tests/autom4te --version autom4te (GNU Autoconf) 2.72d.6-49ab3-dirty (subsecond timestamps supported) Looks good to me. Thanks. a third party C

Re: rhel8 test failure confirmation?

upthread somewhere Karl (iirc) threw out a bikeshed idea like --has=. Pretty sure it wasn't me :).

Re: rhel8 test failure confirmation?

> 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 Karl thinks. I lean towards Jacob's view that automake --

Re: rhel8 test failure confirmation?

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 loaded from other system modules, resulting in the test thinki

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

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

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

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

Re: [PATCH v2] automake: rewrite scan_variable_expansions regex

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

Re: [PATCH] automake: rewrite scan_variable_expansions regex

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

Re: Issue with AM_PROG_LEX

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

Re: Getting long SOURCES lines with subdirs shorter

Hi Jan, Current automake likely won't have anything in store already, Not that I know of. a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c) I've often wanted this myself. I'd certainly welcome a patch for it. Please work from automake trunk. None of the various branches are kept

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

Hi Zack, Date: Fri, 07 Oct 2022 11:35:41 -0400 From: Zack Weinberg [...] the filesystem timestamp resolution was incorrectly detected: Your analysis sounds plausible to me, but it's not obvious to me how best to fix it. ls --full-time or stat may not be available. Maybe just do

Re: faster tests [was: rhel8 test failure confirmation?]

Hi Bogdan, Then, I analysed the files and added the trick from t/backcompat2.sh (if possible) and/or removed the extra calls to $ACLOCAL (if possible). Thanks much for looking into this. Short version: after a few hours of testing and modifications, I *may* have saved up to 1 mi

Re: rhel8 test failure confirmation?

Are you sure about that? Yes. Well, as sure as I can be. I don't see any $(...) constructs in Automake's *.m4 now, and this is certainly deliberate. We discussed shell portability many times over the decades of Automake development. I can't quickly find where it's documented, if anywhere, but

Re: rhel8 test failure confirmation?

Hi Jacob, The guess was the two most probable locations: /usr/share/autoconf and /usr/local/share/autoconf. Wouldn't have worked on my own system :). Challenge accepted. Thanks! if $PERL -I${autom4te_perllibdir:-$(sed -n \ '/autom4te_perllibdir/{s/^.*|| //

Re: rhel8 test failure confirmation?

jb> The test also guesses the location of autoconf's Perl libraries; I'm skeptical that any "guessing" of library locations would be reliable enough. jb> a more thorough test would locate the autom4te script and grep it for the perllibdir that was substituted when autoconf was co

Re: faster tests [was: rhel8 test failure confirmation?]

Is there a way to time individual tests I don't know. Maybe one of the more experienced automakers here can advise. Makes me wonder about having the test infrastructure start each test by running date to get the start time into the log file. Does anyone see a problem with doing that? The m

faster tests [was: rhel8 test failure confirmation?]

# A trick to make the test run muuuch faster, by avoiding repeated # runs of aclocal (one order of magnitude improvement in speed!). echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac Hadn't noticed this before. Maybe you could see what tests are currently taking the longest to run, a

Re: rhel8 test failure confirmation?

I modified my autom4te using the attached patch, Thank you very very much for finding this, Bogdan. I'm glad that Paul has already installed it in Autoconf. I can't easily confirm it for myself right now, but I'm hopeful. (Maybe Frederic or others can try with the development autoconf.) W

Re: rhel8 test failure confirmation?

Note that 'config.h' is older (4 seconds) than './configure', which shouldn't be the case as it should get updated with new values. Indeed. That is the same sort of thing as I was observing with nodef. But what (at any level) could be causing that to happen? Files just aren't getting upda

Re: rhel8 test failure confirmation?

Hi Frédéric, While building the trunk directly led to check failures, Confirmation is good. rebuilding the RPM in a mock environment didn't. Puzzling. I'll likely spend more time next week to perform more testing. It may simply be an environment problem: I guess it's possibl

Re: rhel8 test failure confirmation?

FAIL: t/remake-aclocal-version-mismatch.sh Thanks for trying it, Nick. I'm glad it's not just me. And I sure wonder wtf is going on :(. -k

rhel8 test failure confirmation?

Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux, original RHEL, or even (sort of) CentOS 8? It would be nice if someone could run a make check there (from automake dev). git clone -q git://git.savannah.gnu.org/automake.git cd automake ./bootstrap ./configure && m

  1   2   3   >