bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Spurious error from autoheader


From: Stepan Kasal
Subject: Re: Spurious error from autoheader
Date: Mon, 30 Jun 2008 20:39:42 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Andreas,

On Mon, Jun 30, 2008 at 03:30:19PM +0200, Andreas Schwab wrote:
> $ cat configure.ac
> AC_INIT
> AC_AIX
> AC_DEFINE(__EXTENSIONS__, 1, [Defined on Solaris to see additional function 
> prototypes.])
> AC_CONFIG_HEADERS([config.h])
> AC_OUTPUT
> $ autoheader
> autoheader: warning: missing template: _ALL_SOURCE
> autoheader: Use AC_DEFINE([_ALL_SOURCE], [], [Description])
> autoheader: warning: missing template: _GNU_SOURCE
> autoheader: warning: missing template: _POSIX_PTHREAD_SEMANTICS
> autoheader: warning: missing template: _TANDEM_SOURCE
> 
> The same works when moving AC_AIX down after the AC_DEFINE.

AC_AIX is an alias for AC_USE_SYSTEM_EXTENSIONS these days.

The config.h.in fragment in AC_USE_SYSTEM_EXTENSIONS takes care of
all the above cpp macros, including __EXTENSIONS__, and is "indexed"
by the string __EXTENSIONS__.  This means that the autoheader script
saves it into a hash under index "__EXTENSIONS__".

So it clashes with the config.h.in fragment created from your
AC_DEFINE.  Whoever comes last, wins.  That's why the order matters.

The problem you observe did not happen with Autoconf versions before
the commit from 2007-09-11 which merged AC_AIX into
AC_USE_SYSTEM_EXTENSIONS and the config.h.in fragment there, indexed by
"_ALL_SOURCE" became part of the fragment indexed by __EXTENSIONS__.

An easy fix is to remove AC_DEFINE(__EXTENSIONS_, ...) from
configure.ac, AC_USE_SYSTEM_EXTENSIONS takes care about it.

This problem could be fixed in autoheader by breaking that
config.h.in fragment into more parts, so that your
AC_DEFINE(__EXTENSIONS__, clashes only with one part of it.
But I'm not sure this is worth it.


But I see another problem here:
autoheader calls this "warning", but it does not create
config.h.in then.  Even worse, if config.h.in existed, it's not
updated.
The mistake was introduced by a change almost
5 years old!  The attached diff documents it.

Possible solutions:
- update the template anyway
- call it an error, removing the obsolete template.
- call it an error, leaving template as it is

In my opinion, the above are in decreasing order of preference.

Comments welcome,
        Stepan

Attachment: autoheader-guilty.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]