Re: [sr #110382] In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"'

[Nick Bowler]

On 2023-12-08 09:25, Zack Weinberg wrote:
> Thinking about this one some more, I see two ways to make confdefs.h
> idempotent:
> 
> 1. A conventional "multiple inclusion guard", wrapping the body of the file in
> #ifndef ... #endif.  This will work on all compilers and regardless of whether
> confdefs.h is included or concatenated with the test program, but requires us
> to change AC_DEFINE and friends to do something like
> 
> 
> #define MACRO 1
> 
> 
> The thing I'm worried about with this one is if there's third party macros out
> there somewhere that bypass AC_DEFINE.  The sed construct up there should be
> portable.

I think your sed construct must have been eaten somewhere along the line.  
Without
being able to see the suggestion, I imagine that using sed to rewrite confdefs.h
every time is going to incur quadratic runtime complexity while simply appending
new definitions to an existing file normally does not.

>From what I understand of this issue, I don't think we should change anything
in Autoconf because there does not seem to be any real advantage to fixing this.

  - Excluding the NEWS item which references this one report, the Autoconf 
documentation does not mention confdefs.h even once.  This issue can
only affect packages relying on undocumented Autoconf internals.  It
does not affect normal usage of AC_LANG_SOURCE and friends.

  - We have exactly one report of problems (apr), and this package has been
updated to use AC_LANG_PROGRAM since this was reported.

  - The consequence of this issue is just a compiler warning from a few
versions of one compiler (admittedly an important one).

The bogus warning should just be fixed in gcc.

> 2. Alternatively, use #pragma once and change AC_LANG_CONFTEST(C) to #include
> confdefs.h rather than prepending its contents to the test program.  This
> would keep macros that bypass AC_DEFINE working, but would break with
> compilers that make #pragma once do something wacky (it should be no worse
> than the status quo with compilers that merely _ignore_ #pragma once). I also
> wonder if there's a concrete reason why AC_LANG_CONFTEST(C) _shouldn't_
> #include confdefs.h.

Using nonstandard pragmas seems even worse to me, and just moves the problem
elsewhere (many compilers will warn by default if they encounter "#pragma once"
by default, including older versions of gcc!).

If you really want to work around this gcc bug then it is probably sufficient
to just install special cases in the internal Autoconf macros that generate
these definitions of the problematic macros, for example (untested):

  #ifndef AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define AC_DEFINED__STDC_WANT_IEC_60559_ATTRIBS_EXT__
  #define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
  #endif

Then this could still be inserted to confdefs.h by appending and does not
rely on any nonstandard pragmas.

Cheers,
  Nick

[sr #110561] autoconf: store autom4te request keys in sorted order

[Zack Weinberg]

Update of sr#110561 (group autoconf):

  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Your patch was actually committed over a year ago,
.
 It's good that this bug was left open, though, because it did need adjustment
to work with very old perl, and I'm not sure I would have thought to test with
very old perl if I hadn't been looking at this bug.

The adjustment has now also been landed:
.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110448] AC_CONFIG_AUX_DIRS fails with Windows paths

[anonymous]

Follow-up Comment #2, sr#110448 (group autoconf):

Cabal now sets `$PATH_SEPARATOR=";"` so we don't have the issue anymore with
newer releases:
- https://github.com/haskell/cabal/issues/7494
- https://github.com/haskell/cabal/pull/7510

This issue can be closed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Zack Weinberg]

Update of sr#110318 (group autoconf):

Priority: 7 - Release N (Desirable) => 3 - Release N+1

___

Follow-up Comment #6:

I looked into this a bit more, and it turns out I was wrong, it's not easy. 
autoreconf doesn't currently have the ability to try multiple names for any
tool, and adding that ability would be enough of a change that I think it had
best wait for 2.73.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/