autoheader exit 1 after only warnings

Running autoreconf -Wnone on the attached (quite old) configure.ac gets this output, and nothing else: autoreconf: error: /usr/local/gnu/bin/autoheader failed with exit status: 1 That is, there are no diagnostics. Such a silent failure seems like a bug to me. Looking at the code, it is apparentl

[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop

Follow-up Comment #1, sr#110989 (group autoconf): Zack, isn't that essentially the code you wrote for _AM_FILESYSTEM_TIMESTAMP_RESOLUTION in Automake (sanity.m4)? for am_try_res in $am_try_resolutions; do # Any one fine-grained sleep might happen to cross the boundary # between two values of

Re: m4_foreach_w(...AC_DEFINE...) expansion change in 2.72e?

Hi Zack, Paul, I see the same phenomenon with 2.71 This is the most puzzling thing, since for me I definitely get different results with 2.71 and 2.72e (which is why I reported it). I can't imagine what else in my configure.ac would have caused the difference, but I guess there must be someth

m4_foreach_w(...AC_DEFINE...) expansion change in 2.72e?

2.72e creates a different autoconf.h.in and configure in TeX Live's texk/lcdf-typetools (https://github.com/TeX-Live/texlive-source/tree/trunk/texk/lcdf-typetools): --- autoconf.h.in (revision 69180) +++ autoconf.h.in (working copy) -/* Define to run cfftot1 from otftotfm. */ -#undef H

AC_PROVIDE_IFELSE, AC_FATAL, AC_DEFUN_ONCE not documented

It seems AC_PROVIDE_IFELSE, AC_FATAL, AC_DEFUN_ONCE are not mentioned in the autoconf manual. I noticed them in Akim's ChangeLog entry from 2000, FWIW. It makes me wonder about somehow dumping all AC_* names and comparing to the manual ... 2000-11-01 Akim Demaille Move the `defun' han

AC_PROVIDE{_IFELSE} not documented?

Maybe I'm going blind, but it seems that AC_PROVIDE and AC_PROVIDE_IFELSE are not documented in the Autoconf manual. AC_PROVIDE is mentioned but not described. AC_PROVIDE_IFELSE is not mentioned. $ grep -n AC_PROVIDE autoconf.texi autoconf.texi:14935:@code{AC_DEFUN} or else contain a call to @cod

bug#59406: [Update install instruction for macOS] Update install instruction for macOS

--- a/INSTALL +++ b/INSTALL +On macOS, users should not use the default perl, but manually install +it from https://www.perl.org/get.html. Thanks for the suggestion. I have a couple comments: 1) INSTALL is maintained in Autoconf, not Automake. I'll try to redirect the bug. 2) Why

obsolete replacements (that aren't always)

Thank you for all the information in the Autoconf manual about replacing "obsoleted" macros. A couple comments. AC_FUNC_VFORK is warned about, but not mentioned in the manual anywhere. Maybe it should be another @itemx with AC_VFORK. AC_PROG_LEX is warned about when used without an option. But th

[sr #110416] documentation: ordering of basic macros?

Follow-up Comment #2, sr #110416 (project autoconf): Thanks Zack. That's helpful. The "Autoconf Input Layout" node, with its example, seems pretty good. I don't see any obvious changes to make, at least. Fine with me to close this, if you want. (I'll add some text to the Automake manual about it.)

[sr #110416] documentation: ordering of basic macros?

URL: Summary: documentation: ordering of basic macros? Project: Autoconf Submitted by: karl Submitted on: Sun 03 Jan 2021 06:10:53 PM PST Category: None Priority:

[sr #110397] autoconf 2.70: autotest.m4 error

Follow-up Comment #15, sr #110397 (project autoconf): Oh, I guess "unknown channel" is coming direct from autom4te, not m4. Sorry. That makes it even more mysterious that you get that error and we don't, since I doubt anything in that Perl code is system-dependent. ___

[sr #110397] autoconf 2.70: autotest.m4 error

Follow-up Comment #14, sr #110397 (project autoconf): Did you try with current GNU m4 (1.4.18) in the sandbox? 1.4.6 is ancient. When I see the mysterious m4 message "unknown channel", I have to keep wondering about m4 being the issue. When I run configure in automake-1.4.3 against 2.70, I also g

[sr #110397] autoconf 2.70: autotest.m4 error

Follow-up Comment #9, sr #110397 (project autoconf): Glad that worked, at least. I have no way to know specifically what the problem was. In general, autoconf (and automake subprograms) are a big stress test for m4, and afaik a lot of non-GNU m4's fail. The configure test that reads "checking fo

[sr #110397] autoconf 2.70: autotest.m4 error

Follow-up Comment #7, sr #110397 (project autoconf): Looking at comment #6, the only idea that comes to mind is to try installing GNU m4 and see if that works around the problem. ___ Reply to this item at:

[sr #110399] turning off preference for newest supported C?

Follow-up Comment #3, sr #110399 (project autoconf): When a longstanding core existing feature (AC_PROG_CC) is changed in a backward-incompatible way, a way to get the heretofore standard behavior feels more like a bug fix than a feature request to me. For that matter, it feels like a new macro or

[sr #110399] turning off preference for newest supported C?

URL: Summary: turning off preference for newest supported C? Project: Autoconf Submitted by: karl Submitted on: Wed 09 Dec 2020 02:58:19 PM PST Category: None Prio

[sr #110364] obsolete agony

Follow-up Comment #3, sr #110364 (project autoconf): Well, of course it's not up to me, but I have to argue further. Sorry. It just feels like inflicting a lot of pain on maintainers for the sake of abstract cleanliness. Precisely because these macros have worked fine for so many years, it seems g

[sr #110364] obsolete agony

URL: Summary: obsolete agony Project: Autoconf Submitted by: karl Submitted on: Thu 05 Nov 2020 09:31:47 AM PST Category: None Priority: 5 - Normal

[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

URL: Summary: AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3 Project: Autoconf Submitted by: karl Submitted on: Tue 03 Nov 2020 02:27:50 PM PST Category: None

AC_DIAGNOSE not obsolete, please

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... /home/ttn/local/.b/automake-1.16.2/m4/init.m4:29: AM_INIT_AUTOMAKE

autoconf bug tracking?

Hi Zack and all - um, I guess autoconf is not using the email bug tracker? Do you intend it to? If not, I imagine Bob (cc'd) can disable it completely somehow. (Thanks for the info, Bob.) There is currently one other bug besides the one I just "reassign"ed: https://debbugs.gnu.org/cgi/pkgreport.c

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

So fine to remove from automake after all. Good! So removed. Thanks to all. -k

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

Probably best to leave it, as is, and mark it as known-to-be-unused at least via comment. How does the text below look for an explanation? (By the way, I noticed that FileUtils.pm, unlike the other *.pm in lib/Automake, doesn't have an =over 4 ... =back around all the other items, causing

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

the command that updates autom4te.cache/traces.0 does not modify configure.ac at the same time. No argument for that specific case. But looking at the change in isolation: - if ($mtime < mtime ($dep)) + if ($mtime <= mtime ($dep)) { verb "up_to_date ($file): ou

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

Hi Harald and all - well, Paul or Jim or any other automake worker will know better than me, but my reactions, FWIW: This caused intermittent failures in automake's t/subobj.sh test, which This problem seems like the tip of the iceberg to me. With this change, any dependency which gets update

CRLF vs. LF and config.status defines

Hi everyone - Graham (cc'd) checked out the TeX Live source code on a Windows system, using a mingw64 and msys environment. The autoconf files were generated with (the original, unpatched) autoconf 2.69. The TL configure failed, because the defines[.awk] file created by config.status has a match

Re: CVS Texinfo fails to build the Autoconf manual (from git)

> >* Macro arguments cannot cross lines. > > Is that restriction limited to a per-argument basis (but you can have > newlines between arguments), or is it global to the entire macro call? My guess is that it is per-argument. Maybe Karl can comment on that. I couldn't get

Re: bug#7773: (lack of) config.h description in manual

Proposed patch. OK to push? Works for me. I didn't find a place in the gnulib manual where configmake was explained. Eric explained. I'll write that node in the manual per Bruno's instructions "soon", I hope. Thanks, k

Re: [PATCH 1/2] maint: new rule to update copyright year ranges

In other words Right. Thanks for reading my screed :). +0.1 Basic Installation Oops, thanks for noticing. It's a temporary bug in the development makeinfo that I've been using. I'll regenerate to fix it, no need to change anything in gnulib. k

Re: [PATCH 1/2] maint: new rule to update copyright year ranges

It was added explicitly in Autoconf v2.62-95-g02fa53b for better plaintext rendering, see: http://lists.gnu.org/archive/html/autoconf-patches/2008-08/msg00132.html http://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00239.html Well, sigh. "better" here is an aesthetic opinion,

Re: characters allowed in --enable-*/--with-*

I was merely musing on my experiences in that initial reply, not making final proclamations or anything. Sorry if I gave that impression. I realize there are advantages to allowing +, which you have ably enumerated :). I'm ok with proposing to rms that + be allowed, along with: -_.A-Za-z I wasn

Re: characters allowed in --enable-*/--with-*

So gnulib could have --enable-c++. I guess I missed some discussion on bug-gnulib. Overall, "cplusplus" seems like it would have been simpler/more customary. (That ++ causes endless hassle everywhere.) Easier to remember option names? Dunno. I'd say the opposite: allowing lots of "ran

Re: characters allowed in --enable-*/--with-*

Autoconf 2.66 added '+' to the set of allowed characters in --enable-* Why? So, my question is: could standards.texi document the set of allowed characters? Can you make a proposal? Current Autoconf has -+. mapped to _ and otherwise wants characters eligible for shell variab

Re: backslashes in macro arguments

Other characters that need to be quoted in macro arguments are curly braces and backslash. I committed a new http://ftp.gnu.org/gnu/texinfo/texinfo.tex (and in gnulib, etc., etc.) which purports to handle \\ \{ \} in arguments to macro calls. However, \, can't be handled by the method I

Re: backslashes in macro arguments

Hi All, Changing \t to \\t ... results in a doubled-up \\ in pdf output. I'll see if I can fix that. It is twisty TeX. Trying to use @backslash{}t failed, because there is no @backslash command (should there be?). Conceivably, but it wouldn't really help you now if we added it, sin

Re: backslashes in macro arguments

Hi Ralf, Thanks for the report, as always. need to double backslashes in the macro definition, but is silent about macro arguments. I seem to recall that it is silent precisely because I noted the discrepancy and was too discouraged to do anything about it. I think it is makeinfo that i

"Linux" in comment

How about this (or some such) change in _AC_INIT_DEFAULTS? I surmise it isn't an issue with current systems. At least the hostname on mine (CentOS) returns zero. And anything using GNU hostname is hopefully ok. BTW, the only reason I notice this is because I routinely grep sources of new packag

Re: automake.texi and @acronym

Hi Simon, Is the intention that even the n...@acronym{gnu} cases should be replaced? Then what purpose is the @acronym keyword for? I wrote about that earlier. Minor typographic change which is rarely used in GNU manuals. De facto standard is not to use it. Which is also simpler in th

Re: automake.texi and @acronym

What about @sc{gnu}, which also appears in some but not all GNU manuals? In terms of "logical" markup, @sc should definitely not be used. Typographically, I greatly dislike it (in running text) as well. Is there any difference between @acronym and @sc? Yes. @sc is small caps (=x-height

Re: automake.texi and @acronym

I'm okay with changing the m4 and autoconf manuals with s/@acronym{GNU}/GNU/ s/@acronym{(.*)}/\1/ if we agree that it is easier to maintain, Is to me. and doesn't buy much typographically. I think having the (minor) benefit of consistency between GNU manuals outweighs the (m

Re: automake.texi and @acronym

The texinfo manual even uses @acronym{GNU} as example. It's an example of how to use a Texinfo command. It doesn't necessarily mean that GNU manuals should use it. There are plenty of Texinfo commands which are there for "alternatives". Do you have a rationale for eliminating @acron

Re: license in generated files

Hi Ralf, I'm not sure what you are hinting at here. Sorry, I didn't mean to be "hinting" at anything. I think it's desirable for generated (and non-generated :) files to have explicit licenses. Regardless of whether they are distributed. I don't think distribution matters to these questi

Re: license in generated files

But the license concerns Makefile.in only, since the Makefile is never distributed, no? We don't do it in GNU packages, but it might be in other cases ... And besides, whether the Makefile is distributed or not, it deserves a relevant license statement. In general, it's good for generate

license in generated files

This is really split between autoconf and automake, but I'll just write here for now. 1) The license statement added in Makefile.in starts: .. # This Makefile.in is free software; the Free Software Foundation But then it is copied into the Makefile too, so it's no longer the "Makefile.in". How a

Re: CFLAGS is for the user in GNU

-Automake uses for compilations; for instance, you might need to do your -own compilation in some special cases. +Automake uses for compilations, and in which order (@pxref{Flag +Variables Ordering}); for instance, you might need to do your own +compilation in some special cases

CFLAGS is for the user in GNU

The description of CFLAGS in the Autoconf manual omits the most important point about it. To quote the coding standards (make-stds.texi): If there are C compiler options that @emph{must} be used for proper compilation of certain files, do not include them in @code{CFLAGS}. Users expec

autoconf 2.57 manual still online

I got this result for a recent search (for autoconf shell portability ): http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_114.html I suggest deleting the autoconf-2.57 manual from the online web pages ...

Re: portable use of 'dd'

This particular case is only weak evidence that 'dd' needs to be in the list, since the code uses 'dd' only when /dev/urandom is readable, and I expect that 'dd' is supported everywhere /dev/urandom is. So, I'm inclined to do nothing. /dev/urandom is surely less portable than dd, so t

Re: portable use of 'dd'

Therefore I would suggest to add 'dd' among the "safe" utilities. Granted that dd is certainly more portable than head -c, are we now using it in configure/make such that it has to be listed in the coding standards node? I've never thought of that list in Utilities in Makefiles as being all

checking for headers presence even if usable

I'm not sure if this is really a bug, but I thought I'd mention it. It seems that autoconf 2.62 checks headers for "presence" even if they are already determined to have "usability". For instance, given this configure.ac: AC_INIT([foo], [4.12], [EMAIL PROTECTED]) AC_CHECK_HEADER([stdio.h],

$SHELL for $ac_install_sh?

When a configure script has to fall back on $ac_install_sh for INSTALL or MKDIR_P, how about invoking it via $SHELL, as in the diff below? That way, if install-sh happens not to be executable, it will still work -- it's called with $SHELL in other places. Vincent Lefevre (cc'd, with thanks) repor

Re: make-stds: DESTDIR should be absolute

* doc/make-stds.texi (DESTDIR): Must be an absolute name. Thanks for explaining. I installed the change in the sources. I'll update the web pages a bit later. Thanks, k

Re: make-stds: DESTDIR should be absolute

explicitly specified DESTDIR as an absolute name. Can't a relative path be immediately converted to an absolute path by `cd $arg && pwd` ?

Re: invalid node names in Autoconf manual

I wonder why 'makeinfo' doesn't warn about these node names by default? Because in practice most people prefer to live with the invalid node names and the slight bogosity in the resulting Info files than obfuscate them for the sake of makeinfo :). For some (most?) packages, more people ca

optional documentation formats and targets?

(Sorry for the wide distribution, but I wasn't sure who would be affected, and wanted to seek advice.) Eric Blake from m4 (thanks Eric) asked about the coding standards: And since dvi et. al are not invoked by 'make all', it is not obvious whether 'make install-dvi' should depend on dvi o

Re: reporting full subdir path for subconfigure

Hi folks, Paul> Hmm, it might make the lines rather long, Yes, it could, but I don't see any harm in this case. but on the other hand verbosity is not always bad. Right. It's just more information. Anyone who wants quiet is already (presumably) redirecting the output. What does

reporting full subdir path for subconfigure

It's certainly not a critical issue, but in configuring a complex source tree (TeX Live), I would sometimes find it useful to be told up front exactly what directory is being subconfigured. So, I wonder about changing this line in status.m4: AC_MSG_NOTICE([configuring in $ac_dir]) to somethi