I just got an error from 'make distcheck' that I don't know how to resolve:
ERROR: files left in build directory after distclean:
./.deps/alg-sha512.Plo
./.deps/alg-md4.Plo
./.deps/alg-sha256.Plo
./.deps/randombytes.Plo
./.deps/alg-md5.Plo
./.deps/alg-sha1.Plo
./.deps/alg-des-tables.Plo
./.deps/al
For reasons too complicated to get into here, I have been
experimenting with building shared libraries in an autoconf+automake
build *without* using libtool. [Please do not try to talk me out of
this.] I have something that works correctly on ELF-based operating
systems with GCC, *except* for ins
autoreconf assumes that it can pass --warnings= to both
the tools maintained in Autoconf (autoconf, autoheader, etc.)
and to the tools maintained in Automake (automake, aclocal, etc.)
However, the set of warnings categories defined in autoconf’s
lib/Autom4te/ChannelDefs.pm has diverged from the set
On Thu, Sep 10, 2020 at 6:43 PM Karl Berry wrote:
> Hi Zack - in addition to the other replies, how do you prefer to do the
> sync? (which it seems like we might as well do asap.) From am to ac, or
> from ac to am?
We already sync quite a few Automake/*.pm files from am to ac, so I
think it makes
On Thu, Sep 10, 2020 at 3:39 PM Paul Eggert wrote:
> On 9/10/20 11:48 AM, Zack Weinberg wrote:
> > I’m wondering whether it would make
> > sense to merge this distributor’s patch to avoid supplying -Wcross to
> > automake -- perhaps generalized to arbitrary warning categor
On Mon, Oct 5, 2020 at 5:40 PM Karl Berry wrote:
>
> Zack and all - Thien-Thi (cc'd) just reported two failures in automake
> make check with autoconf-2.69c (bugs.gnu.org/43819). The critical
> message appears to be:
>
> ./lib/autoconf/general.m4:2328: AC_DIAGNOSE is expanded from...
> /ho
Both sets of patches have been pushed. The changes to the Autoconf
manual are slightly different in the version I committed, I found some
small errors on proofreading the patch.
According to
https://codesearch.debian.net/search?q=-pkg%3Aautoconf+%5CbAC_DIAGNOSE%5Cb&literal=0
this would have been
Karl Berry wrote:
> Zack Weinberg wrote:
>> They all appear to be cases of autoconf and/or aclocal
>> getting run when the test suite does not expect them to be run. I am
>> stumped as to why
>
> In short: because the 2.70 autom4te decided not to update configure.
>
On Tue, Jan 5, 2021 at 8:43 AM Bob Friesenhahn
wrote:
> On Mon, 4 Jan 2021, Zack Weinberg wrote:
> >>
> >> Something which surprises me is that the distribution tarballs became
> >> noticeably larger.
> >
> > This is expected. The bulk of the increase is
Now we've all had a while to recover from the long-awaited Autoconf
2.70 release, I'd like to start a conversation about where the
Autotools in general might be going in the future. Clearly any future
development depends on finding people who will do the work, but before
we worry about that I thin
On Wed, Jan 20, 2021 at 5:15 PM Zack Weinberg wrote:
> Now we've all had a while to recover from the long-awaited Autoconf
> 2.70 release, I'd like to start a conversation about where the
> Autotools in general might be going in the future.
> Now we've all had a whi
On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn
wrote:
> At the moment it is a big deal for me because the locking prototol
> that Autoconf/Automake is using does not work with NFS mounts for
> Illumos-derived systems when the client is also an Illumos-derived
> system, because Illumos failed to s
On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn
wrote:
> On Mon, 25 Jan 2021, Zack Weinberg wrote:
> > Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in
> > Automake/XFile.pm) (this code is copied into Autoconf under the
On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn
wrote:
> On Thu, 28 Jan 2021, Zack Weinberg wrote:
> >
> > The main reason I can think of, not to do this, is that it would make
> > the locking strategy incompatible with that used by older autom4te;
> > this could come
I propose that, as of the next major feature release of both Autoconf
and Automake, we raise the minimum version requirement for Perl to
5.18.0. (Currently it is 5.6.0.) On the Autoconf side, the version
number and timeframe for the first release with this change are still
TBD but it would *not*
On Tue, Feb 2, 2021 at 1:19 PM DUDZIAK Krzysztof
wrote:
> Isn't it that strange if for manual* following searches for a string result
> in no matches?
> search for "PLV"
> search for "PSV"
> search for "Product List Variable"
> search for "Product Source Variable"
I've never heard these terms be
On Tue, Feb 2, 2021 at 1:24 PM DUDZIAK Krzysztof
wrote:
> As one can't find string "distcheck" in GCS
By GCS do you mean the GNU Coding Standards?
> it looks like it wasn't GCS
> which constitutes support and usage of `distcheck' target.
> Maybe it is POSIX, or UNIX.
As far as I know, the distc
On Thu, Jan 28, 2021 at 6:51 PM Bruno Haible wrote:
> Zack Weinberg wrote:
> > There is a potential way forward here. The *only* place in all of
> > Autoconf and Automake where XFile::lock is used, is by autom4te, to
> > take an exclusive lock on the entire contents of au
On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote:
I don't know why, but I only received this message today.
> raise the minimum version requirement for Perl to 5.18.0
>
> Sounds sensible to me, for the reasons you outlined.
>
> But, I think it would be wise to give users a way to override th
On Fri, Jan 29, 2021 at 5:54 PM Karl Berry wrote:
I don't know why, but I only received this message today.
> But, I think it would be wise to give users a way to override the
> requirement, of course with the caveat "don't blame us if it doesn't
> work", unless there are true requirements such
On Tue, Mar 9, 2021 at 5:00 PM Tim Rice wrote:
> On Tue, 9 Mar 2021, Warren Young wrote:
> > On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote:
> > Solaris 10 dates from early 2005. We gave it 16 years of direct support,
> > and now it’s on a sort of “extended” support if you point Autoconf
> > co
$ make V=1 dist
make dist-xz dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake'
make distdir-am
make[2]: Entering directory '/home/zack/projects/gnu/autoconf/ci/b-automake'
set -e; set -u; \
if test -d ../s-automake/.git; then \
r
On Wed, Oct 13, 2021, at 11:54 AM, Bob Friesenhahn wrote:
> On Wed, 13 Oct 2021, Zack Weinberg wrote:
>>
>> Looks like some kind of problem with automatic ChangeLog generation?
>
> To me this appears to be the result of skipping an important step in
> what should be the
On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote:
> I think this happened because your CI system has done a shallow clone.
> So the changelog generation failed because the git log is incomplete.
I did a --single-branch clone, but not a shallow one. Shouldn't the trunk be
self-contained?
zw
On Wed, Oct 13, 2021, at 2:32 PM, Nick Bowler wrote:
> On 2021-10-13, Zack Weinberg wrote:
>> On Wed, Oct 13, 2021, at 2:11 PM, Nick Bowler wrote:
>>> I think this happened because your CI system has done a shallow clone.
>>> So the changelog generation failed becaus
On Wed, Feb 9, 2022, at 1:02 AM, Mike Frysinger wrote:
> On 08 Feb 2022 22:11, Glenn Morris wrote:
>>
>> I see autoconf uses savannah for bug reports.
>> So long as simply sending a mail to bug-autoconf doesn't open a savannah
>> issue,
>> I can set the autoconf maintainer to bug-autoconf, so that
On Mon, Sep 26, 2022, at 12:23 PM, Karl Berry wrote:
> Is anyone up for debugging some Python-related test failures on
> RHEL-based systems?
I have access to a RHEL7 system, I know Python, and this sounds much
less unpleasant than everything else I'm supposed to be doing today.
> I have a suspici
On 2022-10-04 6:58 PM, Karl Berry wrote:
With Zack's latest Python fixes, I was hoping to move towards an
Automake release, but I find myself stymied by apparently random and
unreproducible test failures. I haven't exhausted every conceivable
avenue yet, but I thought I would write in hopes that
On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote:
> On 2022-10-04 6:58 PM, Karl Berry wrote:
>> Perhaps easier to debug: there are two targets to be run before making a
>> release, check-no-trailing-backslash-in-recipes and check-cc-no-c-o,
>> to try to ensure no reversi
On Thu, Oct 6, 2022, at 4:25 PM, Karl Berry wrote:
> No errors on RHEL7+autoconf2.71
>
> Puzzling. Can you easily try RHEL8 or one of its derivatives?
> It surprises me that that is the culprit, but it seems possible.
Unfortunately, no. CMU is mostly an Ubuntu shop these days. It's only dumb
lu
On Thu, Oct 6, 2022, at 4:19 PM, Zack Weinberg wrote:
> On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote:
>> On 2022-10-04 6:58 PM, Karl Berry wrote:
>>> Perhaps easier to debug: there are two targets to be run before making a
>>> release, check-no-trailing-backslash
Please don't top-post on this mailing list.
On Tue, Oct 11, 2022, at 12:15 PM, Frederic Berat wrote:
> On Fri, Oct 7, 2022 at 6:11 PM Zack Weinberg wrote:
>> On Thu, Oct 6, 2022, at 4:25 PM, Karl Berry wrote:
>>>> No errors on RHEL7+autoconf2.71
>>>
>>&g
On Thu, Dec 8, 2022, at 5:18 AM, aotto wrote:> Hi,
> I use "automake" to setup a "gnu make" build-environment and I have the
> following rule to create a special file:
> Problem: the "$(c_Meta)" failed with error but MAKE continue… why??
...
> $(csmkkernel_meta) $(csmqmsgque_meta) $(cslcconfig_met
On Mon, Dec 12, 2022, at 5:57 PM, Karl Berry wrote:
> Zack, would you like be co-maintainer or at least co-developer of
> Automake? There is, evidently, no one else in the world interested in
> being actively involved with Automake on the maintainer side.
I have to decline; I don't have anything l
On Thu, Jan 12, 2023, at 9:24 PM, Eduardo Hernández wrote:
> I've been trying to separate the build system and source directory
> completely. Part of that would be to have the 'configure' script in the
> 'build' directory, away from the 'src' directory
This goes against a basic design assumption i
On Tue, Apr 4, 2023, at 3:51 PM, Bogdan wrote:
> Nice. The 0 and 1 may not be portable to each OS in the Universe
> (see EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be
> good/portable enough for our goals. Or maybe some other simple solution.
ISO C guarantees that exit(0) has the sam
On Mon, Jul 31, 2023, at 7:37 AM, FX Coudert wrote:
> Hello,
>
> I have a configure.ac file that calls AM_PROG_LEX. This now generates
> warnings:
...
> I am not sure I can actually fix those: AM_PROG_LEX does not seem to
> accept an argument. Probably it should, and pass it down to AC_PROG_LEX
On Sat, Sep 30, 2023, at 1:07 AM, Jan Engelhardt wrote:
> On Saturday 2023-09-30 05:27, Dave Hart wrote:
>
>>I've added code to the ntp.org Makefile.am files to ensure the static
>>utility library libntp.a is up-to-date for each program that uses it, to
>>ensure the build is correct. When building
On Sat, Dec 2, 2023, at 6:58 AM, Mike Frysinger wrote:
> On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
>> Karl Berry wrote:
>> > jb> a more thorough test would locate the autom4te script and grep it
>> > for the perllibdir that was substituted when autoconf was
>> > configured.
>> >
>> >
On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> The best way to check if high-resolution
> timestamps are available to autom4te is to have perl load
> Autom4te::FileUtils and check if that also loaded Time::HiRes.
>
> The problem with that turned out to be that Time::HiRes got loaded
On Sat, Dec 2, 2023, at 7:33 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> Would it help if we added a command line option to autom4te that made
>> it report whether it thought it could use high resolution timestamps?
>> Versions of autom4te that didn't recog
On Sat, Dec 2, 2023, at 8:58 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> Either way is no problem from my end, but it would be more work
>> for automake (parsing --version output, instead of just checking the
>> exit status of autom4te --assert-high-resolution-times
On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
>> There would not need to be much parsing, just "automake --version | grep
> > HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> > easc" to avoid running grep if you want.
>
> I specifically want to hear what Kar
The Automake test suite wants this in order to know if it’s safe to
reduce the length of various delays for the purpose of ensuring files
in autom4te.cache are newer than the corresponding source files.
* lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag
$subsecond_mtime, indicating
On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote:
> Now that I have seen the actual patch, yes, this test should be
> accurate. The test in the main autom4te script will also work, even
> if there is a mismatch between the script and its library
Good.
> This appears to be misaligned with t
On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
[snip everything addressed in the other thread]
> Yes, there was a bit of confusion here; not only is the FileUtils
> module synchronized between autom4te and automake
Thanks for reminding me that I need to
The Automake test suite wants this in order to know if it’s safe to
reduce the length of various delays for the purpose of ensuring files
in autom4te.cache are newer than the corresponding source files. We
can also take advantage of this to speed up a couple of tests in our
own testsuite.
* lib/A
On Tue, Dec 5, 2023, at 11:30 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> $ autom4te --version
>> autom4te (GNU Autoconf) 2.71
>> Features: subsecond-timestamps
>>
>> Copyright (C) 2021 Free Software Foundation, Inc.
>> License GPLv3+/Autocon
One of Autoconf's regression tests includes:
# If Autoconf is too old, or the user has turned caching off, skip:
AT_CHECK([aclocal || { ret=$?; test $ret -eq 63 && ret=77; exit $ret; }],
[], [], [ignore])
The effect is to skip the rest of the test if aclocal's exit status is 63.
This cod
In case anyone is waiting for me to respond to questions or write a patch or
anything, please be advised that my work computer has crashed hard and until
replacement components arrive (early next week) I can't do much of anything.
On Sun, Mar 31, 2024, at 3:17 AM, Jacob Bachmeyer wrote:
> Eric Gallager wrote:
>> Specifically, what caught my attention was how the release tarball
>> containing the backdoor didn't match the history of the project in its
>> git repository. That made me think about automake's `distcheck`
>> targe
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
> "Zack Weinberg" writes:
>> It might indeed be worth thinking about ways to minimize the
>> difference between the tarball "make dist" produces and the tarball
>> "git archive" produces, sta
On Tue, Apr 9, 2024, at 11:35 PM, Jacob Bachmeyer wrote:
> Jan Engelhardt wrote:
>> On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote:
>>
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance, output
"via stdin" a
On Thu, Jun 6, 2024, at 10:37 AM, Dan Kegel wrote:
> That's a really good idea. Automake and Autotools in general underpin
> a fair amount of key open source software, but is taken for granted.
>
> Ideas for making the case for funding: identify...
> - how many commonly used Debian/Ubuntu/Alpine p
On Tue, Jun 11, 2024, at 7:00 PM, Karl Berry wrote:
> 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 Automa
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 co
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
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:
> -
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 wh
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 Auto
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
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 Ma
On Sat, Jul 6, 2024, at 12:36 AM, Shiro Kawai wrote:
> Hi there, my first post to this list.
> I was browsing config.sub and stumbled on a possible typo.
You are correct. I posted the same patch more than a month ago but
it has not been applied.
FYI, patches to config.sub and config.guess go to
On Thu, Jul 18, 2024, at 5:09 AM, Tijl Coosemans wrote:
> Automake 1.17 produces a warning for the use of \# here:
>
> https://github.com/ddclient/ddclient/blob/d88e6438efbc53e977546693f6835f7517072a06/Makefile.am#L22
For reference, the construct in question is
subst = sed \
-e 's|@PACKAGE
On Thu, Jul 18, 2024, at 1:50 PM, Jan Engelhardt wrote:
> On Thursday 2024-07-18 15:40, Zack Weinberg wrote:
>>On Thu, Jul 18, 2024, at 5:09 AM, Tijl Coosemans wrote:
>>> Automake 1.17 produces a warning for the use of \# here:
>>>
>>> https
On Thu, Jul 18, 2024, at 2:21 PM, Zack Weinberg wrote:
> On Thu, Jul 18, 2024, at 1:50 PM, Jan Engelhardt wrote:
>> On Thursday 2024-07-18 15:40, Zack Weinberg wrote:
>>>On Thu, Jul 18, 2024, at 5:09 AM, Tijl Coosemans wrote:
>>>> Automake 1.17 produces a
On Wed, Jul 31, 2024, at 9:56 AM, Detlef Riekenberg wrote:
> For all contributions, they have to be checked, commented and later
> committed by the few busy people with commit rights.
Because of this ...
> We need a list of "todo projects", similar to what is available for
> projects, who apply f
On Sat, Sep 28, 2002 at 04:46:21PM -0700, Bruce Korb wrote:
>
> For the time being, I'll test for GCC 3.[12] and disable
> optimization for that compiler, I guess. :-(
If you've found an optimizer bug in 3.[12] not present in 3.0 and
prior, you could have the courtesy to *tell us what it is* so
On Tue, Oct 15, 2024, at 10:38 AM, suzuki toshiya wrote:
> I'm looking for a combination of the target to include sub-packages
> which is built conditionally.
>
> A package "X" include a libary "Y" as a subpackage, like
...
> Y is often installed as an external or system library, so X/configure
> c
On Fri, Jan 31, 2025, at 12:22 PM, Karl Berry wrote:
> Maybe Automake shouldn't use:
> use warnings FATAL => 'all';
>
> Changed to just "use warnings;", as Jacob also noted.
>
> I also took the opportunity to systematize on
> use 5.006; use strict; use warnings;
> all on one line to reduc
On Tue, Dec 17, 2024, at 12:24 PM, Ross Burton wrote:
> On 17 Dec 2024, at 17:17, Nick Bowler wrote:
>> Adding the automake list, because (mostly for historical reasons)
>> aclocal is actually part of automake, not autoconf.
>
> I’ve been using autotools for too many years and I _still_ forget wha
On Tue, Feb 18, 2025, at 8:39 AM, Christoph Grüninger via Discussion list for
the autoconf build system wrote:
> Dear Autoconf,
>
> I am interested in the state and plans for supporting C++20 modules.
As far as I know, nobody is currently working on anything related to C++
2020 in either Autoconf
On Mon, Jun 2, 2025, at 12:12 PM, Nick Bowler wrote:
> On Sun, Jun 01, 2025 at 06:48:38PM -0500, Bob Friesenhahn wrote:
>> It seems a shame that a distribution tarball will lack a source file
>> due to makefile build rules. Build rules are a simple technical
>> issue, which have been solved before,
On Mon, Jun 2, 2025, at 3:58 PM, Nick Bowler wrote:
> Automake has a script called "bootstrap", the documentation says it is
> used to generate configure (and other files), presumably it was
> actually used for this purpose, and therefore it should be included.
Automake (and Autoconf)'s bootstrap
74 matches
Mail list logo
