AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore

AC_INCLUDES_DEFAULT (which is used implicitly by a great many checks) goes and checks for a bunch of headers that are either guaranteed to exist by default on all platforms of interest nowadays, or guaranteed to be *unnecessary* on all platforms of interest nowadays: consider AC_INIT(_, _, _) AC_

Re: AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore

On Wed, Apr 4, 2012 at 7:28 PM, Paul Eggert wrote: > No doubt the set of default headers > should be modernized, but it's going too far, I expect, > to have Autoconf assumes that headers like > exist.  Autoconf-generated scripts are sometimes used > to configure on MSVC platforms, for example, an

Re: AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore

On Wed, Apr 4, 2012 at 7:41 PM, Russ Allbery wrote: > I think you're assuming a hosted target.  I'm not sure that you can make > that assumption.  Can't Autoconf be used to cross-compile software for a > free-standing target, where several of those header files are not > required to exist? Progra

Removal of double check from AC_CHECK_HEADER (was Re: AC_INCLUDES_DEFAULT does not need to probe...)

I meant to ask: is there a planned schedule for getting rid of the "mongrel" double check that AC_CHECK_HEADER[S] does if you don't supply a fourth argument? It seems to me that there has been quite some time since it was introduced, and nowadays it's growing quite rare to find a header that doesn

Re: socket code on Windows (was: AC_INCLUDES_DEFAULT does not need to probe for headers that are part of C89 or POSIX.1 anymore)

On Thu, Apr 12, 2012 at 10:36 AM, Russ Allbery wrote: > Zack Weinberg writes: > >> The least-POSIXy environment this program is ever likely to be ported to >> is Windows -- advice on how to make code that assumes BSD socket headers >> compile with Winsock would be signifi

[sr #110210] nasm fails with autoconf master

Update of sr #110210 (project autoconf): Open/Closed:Open => Closed ___ Follow-up Comment #2: Fixed in 0a0a3378866bacf37dd2dcc325cb838b69bdb485. ___

[sr #110211] flex fails with autoconf master

Update of sr #110211 (project autoconf): Open/Closed:Open => Closed ___ Follow-up Comment #1: Fixed in 0a0a3378866bacf37dd2dcc325cb838b69bdb485. ___

[sr #106256] configure removed source file named a.h

Update of sr #106256 (project autoconf): Open/Closed:Open => Closed ___ Reply to this item at: ___

[sr #100224] Makefile:161: *** missing separator.

Update of sr #100224 (project autoconf): Status:None => Need Info ___ Follow-up Comment #1: This bug report is very old and I do not have the appropriate environment in which to attempt t

[sr #101215] 2.49d is not there

Update of sr #101215 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: The link to ftp://

[sr #105403] AC_CONFIG_HEADER obsolete?

Update of sr #105403 (project autoconf): Priority: 5 - Normal => 3 - Low Status:None => Confirmed ___ Follow-up Comment #2: It appears that AC

[sr #106943] autotest macros require double quotes now

Update of sr #106943 (project autoconf): Open/Closed:Open => Closed ___ Follow-up Comment #2: This was fixed a long time ago. ___ R

[sr #107240] AutoConf documentation needs simple example

Update of sr #107240 (project autoconf): Priority: 5 - Normal => 3 - Low Status:None => Confirmed ___ Follow-up Comment #4: This is still a de

[sr #107444] constructs generated by autoconf do not work in the ash shell

Update of sr #107444 (project autoconf): Status: Need Info => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #4: We never heard bac

[sr #107450] "warning: AC_INIT: not a literal:" on '?

Update of sr #107450 (project autoconf): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: This was fixed a l

[sr #107447] error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl

Update of sr #107447 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: This was fixed a l

[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

Update of sr #107986 (project autoconf): Status:None => Need Info ___ Follow-up Comment #5: Hm, I think this is still a desirable change and could be merged for 2.70. David Wheeler, if y

[sr #108182] [doc] Clarification for behaviour of AC_CHECK_FILES

Update of sr #108182 (project autoconf): Open/Closed:Open => Closed ___ Follow-up Comment #3: Closing; this patch will be included in the upcoming 2.70 release. ___

[sr #108144] ./configure could recommend packages to install through local package manager

Update of sr #108144 (project autoconf): Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing this old, declined feature request. __

[sr #108092] AC_PROG_GREP can select /usr/xpg4/bin/grep under Solaris 9 but it doesn't support long lines

Update of sr #108092 (project autoconf): Priority: 5 - Normal => 1 - Later Status:None => Confirmed ___ Follow-up Comment #1: We apologize for n

[sr #108278] AC_CANONICAL_BUILD depends on install-sh, but it does not get installed

Update of sr #108278 (project autoconf): Priority: 5 - Normal => 1 - Later Severity: 3 - Normal => 1 - Wish Status:None => Confirmed _

[sr #108843] new cpu type NEC SX-ACE

Update of sr #108843 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing this bug a

[sr #108879] Add m4_forbid_pattern for autoconf-archive macros

Update of sr #108879 (project autoconf): Priority: 5 - Normal => 1 - Later Severity: 3 - Normal => 1 - Wish Status:None => Confirmed _

[sr #109320] _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB correctly using the original AT&T lex if Xcode's flex is installed

Update of sr #109320 (project autoconf): Status:None => Confirmed ___ Follow-up Comment #1: Thank you for the nice clear bug report with included patch, and we apologize for the delay get

[sr #110214] autoreconf passes -Wcross to aclocal/automake but they don't support that

Update of sr #110214 (project autoconf): Priority: 5 - Normal => 1 - Later Status:None => Confirmed ___ Follow-up Comment #1: Confirmed, but I'm

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

Update of sr #110212 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Reply to this item at: ___

[sr #110215] AC_EGREP_HEADER appears to be broken in master

Update of sr #110215 (project autoconf): Status:None => Need Info ___ Follow-up Comment #2: Before I close this, could you please explain in a little more detail what the "user error" act

[sr #110216] Add gtkdocize/intltoolize support to autoreconf

Update of sr #110216 (project autoconf): Severity: 3 - Normal => 1 - Wish Status:None => Confirmed ___ Follow-up Comment #1: These look like re

[sr #110215] AC_EGREP_HEADER appears to be broken in master

Update of sr #110215 (project autoconf): Status: Need Info => Confirmed ___ Follow-up Comment #3: Never mind, I found the discussion on bug-autoconf. This *is* arguably a regression from 2.69.

[sr #110213] curl fails with autoconf master

Update of sr #110213 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: Per discussion at

[sr #109676] only one "checking whether the AC_LANG compiler works"

Update of sr #109676 (project autoconf): Priority: 5 - Normal => 1 - Later Status:None => Confirmed ___ Follow-up Comment #1: Confirmed. Thank

[sr #108503] Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB

Update of sr #108503 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: This is a bug in l

[sr #108503] Running autoscan in a directory with ltmain.sh produces conflicting warnings with libtoolize about AC_PROG_RANLIB

Follow-up Comment #2, sr #108503 (project autoconf): Filed bug #110261 on Libtool. ___ Reply to this item at: ___

[sr #100649] out-of-date links in manual

Follow-up Comment #1, sr #100649 (project autoconf): Filed bug #110261 on libtool. ___ Reply to this item at: ___

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

Update of sr #110212 (project autoconf): Status:None => Postponed ___ Follow-up Comment #2: Savannah doesn't have a good way of tagging bugs that are blocked on some external change, so I

[sr #107240] AutoConf documentation needs simple example

Update of sr #107240 (project autoconf): Status: Confirmed => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #5: On further thought

[sr #109320] _AC_PROG_LEX_YYTEXT_DECL fails to compute LEXLIB correctly using the original AT&T lex if Xcode's flex is installed

Update of sr #109320 (project autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Patch merged with

[sr #110215] AC_EGREP_HEADER appears to be broken in master

Update of sr #110215 (project autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #4: AC_PROG_EGREP adde

[sr #105403] AC_CONFIG_HEADER obsolete?

Update of sr #105403 (project autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: As of a1acd8e66b7a

[sr #109513] Release Autoconf 2.70

Update of sr #109513 (project autoconf): Status:None => In Progress Assigned to:None => zackw ___ Follow-up Comment #1: A beta release, Au

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

URL: Summary: Testsuite regressions from 2.69 on Solaris 10 (SPARC) Project: Autoconf Submitted by: zackw Submitted on: Wed 15 Jul 2020 12:16:19 AM UTC Category: None

[sr #110266] Revert regression in Yacc support, and add Bison support

Update of sr #110266 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Follow-up Comment #2: Yeah, I think AC_PROG_BISON would be 2.71 material at this point. Considering the course of th

[sr #110216] Add gtkdocize/intltoolize support to autoreconf

Update of sr #110216 (project autoconf): Status: Confirmed => Need Info ___ Reply to this item at: ___

[sr #110216] Add gtkdocize/intltoolize support to autoreconf

Update of sr #110216 (project autoconf): Status: Need Info => Need Copyright Assignment ___ Reply to this item at: _

[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

Update of sr #107986 (project autoconf): Status: Need Info => Need Copyright Assignment ___ Reply to this item at: _

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Follow-up Comment #1, sr #110267 (project autoconf): I've pushed a partial fix for this. As of revision 71b5037a, tests 365 367 390 391 392 393 394 395 396 397 398 399 400 should pass. 209 appears to be an intermittent race condition in the parallel testsuite driver, not Solaris-specific; I will

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

URL: Summary: 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH Project: Autoconf Submitted by: zackw Submitted on: Mon 27 Jul 2020 01:55:03 PM UTC Cate

[sr #110284] 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH

URL: Summary: 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH Project: Autoconf Submitted by: zackw Submitted on: Mon 27 Jul 2020 02:01:10 PM UTC Category:

[sr #110284] 2.69b on OpenIndiana: one testsuite failure with GNU utilities in $PATH

Update of sr #110284 (project autoconf): Status:None => Need Info ___ Follow-up Comment #1: The key part of the logfile reads /home/bfriesen/src/gnu/autoconf-2.69b/tests/fortran.at:989:

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

Update of sr #110283 (project autoconf): Status:None => Ready For Test ___ Follow-up Comment #1: It appears that many of the failures are spurious, caused by ksh93's _AST_FEATURES shell variab

[sr #110285] Probes for C++11 and C11 are too slow

URL: Summary: Probes for C++11 and C11 are too slow Project: Autoconf Submitted by: zackw Submitted on: Mon 27 Jul 2020 06:24:27 PM UTC Category: None Priority: 5

[sr #110286] Make it possible to request a specific (non-latest) version of a language standard

URL: Summary: Make it possible to request a specific (non-latest) version of a language standard Project: Autoconf Submitted by: zackw Submitted on: Mon 27 Jul 2020 06:31:37 PM UTC

[sr #110289] "/bin/sh: line 1: ../tests/mktests.sh: not found" with dmake and separate build dir

URL: Summary: "/bin/sh: line 1: ../tests/mktests.sh: not found" with dmake and separate build dir Project: Autoconf Submitted by: zackw Submitted on: Tue 04 Aug 2020 01:16:20 PM UTC

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

Follow-up Comment #4, sr #110283 (project autoconf): I have been able to reproduce the _AST_FEATURES problem on weerd when $PATH is set to /usr/xpg4/bin:/usr/bin:/usr/sbin:/sbin. I'm testing my patch now and I will push it after verifying it fixes the issue. _

[sr #110283] 2.69b on OpenIndiana: many testsuite failures without GNU utilities in $PATH

Update of sr #110283 (project autoconf): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #5: The patch I posted

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Follow-up Comment #3, sr #110267 (project autoconf): > 'make' is in /usr/ccs/bin on Solaris 11.1 and earlier. Thanks. I'm sure I used to know that, but I haven't needed to do development on Solaris systems in a long time. Dagobert kindly installed a version of Sun C on gcc210.fsffrance.org that

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Update of sr #110267 (project autoconf): Status:Works For Me => In Progress ___ Reply to this item at: ___

[sr #110285] Probes for C++11 and C11 are too slow

Update of sr #110285 (project autoconf): Status: In Progress => Ready For Test ___ Follow-up Comment #2: I just pushed a commit (c16be715) that makes the C++98 and C++11 test programs exercise only *l

[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

Update of sr #107986 (project autoconf): Status: Need Copyright Assignment => Done Open/Closed:Open => Closed ___ Follow-up Comment #7: I wound up re-do

[sr #110216] Add gtkdocize/intltoolize support to autoreconf

Update of sr #110216 (project autoconf): Status: Need Copyright Assignment => Done Open/Closed:Open => Closed ___ Follow-up Comment #4: Merged as dd880a

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Follow-up Comment #4, sr #110267 (project autoconf): The spurious failure due to a broken Go compiler is fixed in fa0754f704d7442cb2780d740fa4aabe2ba19f86. ___ Reply to this item at: __

[sr #110289] "/bin/sh: line 1: ../tests/mktests.sh: not found" with dmake and separate build dir

Update of sr #110289 (project autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: It was a little mo

[sr #110297] AC_PATH_PROG should accept a basename as an override

URL: Summary: AC_PATH_PROG should accept a basename as an override Project: Autoconf Submitted by: zackw Submitted on: Wed 26 Aug 2020 01:57:49 PM UTC Category: None

[sr #110297] AC_PATH_PROG should accept a basename as an override

Update of sr #110297 (project autoconf): Priority: 5 - Normal => 1 - Later Assigned to: zackw => None ___ Follow-up Comment #1: This is a long-sta

[sr #109513] Release Autoconf 2.70

Follow-up Comment #2, sr #109513 (project autoconf): Status update: I plan to put out a second beta release as soon as I can get the core testsuite to a point where I'm happy with it on Solaris and NetBSD, and also do something about #110286 and #110294. This should hopefully happen early next we

[sr #110298] "Substitute and define special characters" test fails on NetBSD

URL: Summary: "Substitute and define special characters" test fails on NetBSD Project: Autoconf Submitted by: zackw Submitted on: Wed 26 Aug 2020 09:28:46 PM UTC Category: None

[sr #110298] "Substitute and define special characters" test fails on NetBSD

Update of sr #110298 (project autoconf): Priority: 5 - Normal => 1 - Later Status:None => Confirmed ___ Follow-up Comment #1: The same failure o

[sr #110300] configure >/dev/full does not fail promptly

URL: Summary: configure >/dev/full does not fail promptly Project: Autoconf Submitted by: zackw Submitted on: Fri 28 Aug 2020 02:54:33 PM UTC Category: None Priori

[sr #110300] configure >/dev/full does not fail promptly

Update of sr #110300 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Follow-up Comment #1: This is a long-standing issue. Also, the cleanest way to detect these errors would be to turn

Re: autoconf bug tracking?

On Thu, Sep 3, 2020 at 5:59 PM Karl Berry wrote: > > 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.) Autoconf is currently using the Savannah built-in b

Re: autoconf bug tracking?

On Thu, Sep 3, 2020 at 8:26 PM Bob Proulx wrote: > > We have this list of projects that have been configured for the GNU > BTS instance running on debbugs. > > https://debbugs.gnu.org/Packages.html > > As you can tell there are quite a few. But it's not all projects. > It's projects that have

configure script for GNU sed 4.8 generated by buggy unreleased Autoconf (was re: "configure" tries to execute what seems to be a shell command)

On Sat, Sep 5, 2020 at 7:51 AM Sidney Cadot wrote: > When running ./configure (or even just ./configure --help), an execve() > syscall is done to execute what seems to be a shell command. > > Usually the first argument to execve() is something like "/bin/sed" or > "/usr/bin/gawk", but in this case

Re: configure script for GNU sed 4.8 generated by buggy unreleased Autoconf (was re: "configure" tries to execute what seems to be a shell command)

On Sat, Sep 5, 2020 at 4:18 PM Sidney Cadot wrote: > (As an aside: I was surprised to see the number of processes that > were started even when just doing a “./configure --help” (36 in all, > including stuff like ‘rm', ‘mkdir', ‘chown’, and ‘ln’). To someone > like me who is not familiar with the

Re: inconsistent seach orders in AC_PATH_PROGS vs AC_PATH_PROGS_FEATURE_CHECK

On Thu, Sep 10, 2020 at 7:23 AM wrote: > > One expects that the macro AC_PATH_PROGS_FEATURE_CHECK > traverses the list of programs in its 2nd argument > in the same way as AC_PATH_PROGS, > i.e. the outermost loop is over the list of programs. > > But in AC_PATH_PROGS_FEATURE_CHECK the outer loop

Re: doc: Fix cross-reference for AC_TRY_LINK

On Tue, Sep 22, 2020 at 8:40 AM Jonathan Wakely wrote: > > The documentation for AC_TRY_LINK at > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html > has a cross-reference to "Running the Compiler". Presumably this > should be "Running the Linker" instead. >

[sr #110214] autoreconf passes -Wcross to aclocal/automake but they don't support that

Update of sr #110214 (project autoconf): Priority: 1 - Later => 5 - Normal Status: Confirmed => Done Open/Closed:Open => Closed _

[sr #110285] Probes for C++11 and C11 are too slow

Update of sr #110285 (project autoconf): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: I'm going to mark

[sr #110312] 2.69b: broken AC_PROG_LEX macro

Follow-up Comment #2, sr #110312 (project autoconf): Could you please construct and send us a minimal configure.ac that reproduces this behavior? Also, it would be helpful to see the output of find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \) -ls __

[sr #110312] 2.69b: broken AC_PROG_LEX macro

Follow-up Comment #3, sr #110312 (project autoconf): The output of these commands would also be really helpful: nm --defined-only /usr/lib64/libfl.a nm --dynamic --defined-only /usr/lib64/libfl.so ___ Reply to this item at:

[sr #110306] Upstream: netbsd/patch-aa

Update of sr #110306 (project autoconf): Status:None => Works For Me Open/Closed:Open => Closed ___ Follow-up Comment #1: Verified that 2.69

[sr #109513] Release Autoconf 2.70

Follow-up Comment #3, sr #109513 (project autoconf): Status update: The second beta, Autoconf 2.69c, has been released: https://lists.gnu.org/archive/html/autoconf/2020-09/msg6.html The plan is to make the final release of Autoconf at the end of October. _

[sr #110317] Upstream: oe/autotest-automake-result-format.patch

URL: Summary: Upstream: oe/autotest-automake-result-format.patch Project: Autoconf Submitted by: zackw Submitted on: Thu 24 Sep 2020 06:36:37 PM UTC Category: None

[sr #110317] Upstream: oe/autotest-automake-result-format.patch

Update of sr #110317 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Reply to this item at: ___

[sr #110308] Upstream: yocto/autoreconf-exclude.patch

Update of sr #110308 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Reply to this item at: ___

[sr #110307] Upstream: netbsd/patch-lib_autoconf_fortran.m4

Update of sr #110307 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Reply to this item at: ___

[sr #110318] autoreconf: support libtoolize being named glibtoolize

URL: Summary: autoreconf: support libtoolize being named glibtoolize Project: Autoconf Submitted by: zackw Submitted on: Thu 24 Sep 2020 06:55:29 PM UTC Category: None

[sr #110318] autoreconf: support libtoolize being named glibtoolize

Update of sr #110318 (project autoconf): Priority: 5 - Normal => 1 - Later ___ Follow-up Comment #1: 2.61 was a long time ago. I'm wondering if Gentoo still ships 'glibtoolize' and not 'libtooliz

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)

Update of sr #110267 (project autoconf): Priority: 5 - Normal => 1 - Later Status: In Progress => Need Info ___ Follow-up Comment #5: The Make-related f

[sr #110312] 2.69b: broken AC_PROG_LEX macro

Follow-up Comment #6, sr #110312 (project autoconf): Thanks. I understand how your system is set up now, I think. I still need that minimal configure.ac that reproduces the behavior to make any progress. ___ Reply to this item at:

[sr #110319] autoconf incompatible change not fixed by autoupdate

Update of sr #110319 (project autoconf): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: I confirm the prob

[sr #110312] 2.69b: broken AC_PROG_LEX macro

Update of sr #110312 (project autoconf): Status:None => Need Info ___ Follow-up Comment #7: I cannot reproduce the problem with this configure.ac: AC_INIT([bug-110312], [1.0]) AC_PROG_L

Re: [GNU Autoconf 2.69] testsuite: 503 failed

On Mon, Oct 5, 2020 at 1:50 PM Ghassan Sarrouh wrote: > > I’m trying to install GNU Autoconf 2.69 but it failed the “>> make check” > step, after running “>> make” but prior to running “>> make install”. I have > attached the testsuite.log file, as per the Error 503 instructions. Please > reply

Re: AC_DIAGNOSE not obsolete, please

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

Re: AC_DIAGNOSE not obsolete, please

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

[sr #110331] autoreconf aborts if AC_CONFIG_SUBDIRS() has no arguments

Update of sr #110331 (project autoconf): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: Fixed in b0d20c049

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

On Tue, Oct 20, 2020 at 4:57 PM Nick Bowler wrote: > On 2020-10-20, Sergei Trofimovich wrote: > > Initial bug is reported as autoconf failure on ghc-8.8.4: > > https://bugs.gentoo.org/750191 > > There autconf 2.69 works, 2.69c does not. ... > > $ cat configure.ac > > AC_INIT([The Glorious

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert wrote: > > On 10/21/20 6:15 AM, Zack Weinberg wrote: > > We*could* add a special case in AC_INIT where, if any of the third, > > fourth, or fifth arguments contain the literal strings > > `AC_PACKAGE_NAME` or `AC_PACKAGE_VERS

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

On Thu, Oct 22, 2020 at 11:53 AM Nick Bowler wrote: > On 2020-10-22, Zack Weinberg wrote: > > On Wed, Oct 21, 2020 at 10:25 PM Paul Eggert wrote: > >> > >> On 10/21/20 6:15 AM, Zack Weinberg wrote: > >> > We*could* add a special case in AC_INIT where,

Re: AC_PACKAGE_VERSION visibility slightly changed in autoconf-2.69c. Bug or feature?

On Thu, Oct 22, 2020 at 12:20 PM Nick Bowler wrote: ... > > And it also works as expected with the zack/ac-init-quoting branch if I > > simply revert the patch hunks identified earlier in this thread: > > > > % autoconf-zack-patched > > % ./configure > > 2.69c.10-6487-dirty > > foo-bug@[19

Re: AC_CHECK_HEADER/AC_CHECK_DECL 2.69->2.69c probably changed quoting, breaks gimp as "...: ${+y}: bad substitution"

On Sun, Oct 25, 2020 at 9:13 AM Sergei Trofimovich wrote: ... > gimp's use of macros looks underquoted Yes, this is an underquotation problem, and also a "macros that use AC_REQUIRE internally are not safe to use inside hand-coded shell conditionals" problem. This particular example is so badly

  1   2   3   4   5   >