[Top][All Lists]
[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
autoheader-guilty.patch
Description: Text document