Re: accepted by the compiler, rejected by the preprocessor!

2003-03-21 Thread Thomas Dickey
On Fri, Mar 21, 2003 at 02:21:21PM -0800, Paul Eggert wrote:
> "Dr. David Kirkby" <[EMAIL PROTECTED]> writes:
> 
> > I'm not quite sure how a header file can be usable, but not present!!
> 
> The next version of Autoconf will have some documentation about this.
> Here's the current draft, written by Akim Demaille, in Texinfo format:

...which hasn't been proofread, obviously (take your time - I spotted a
couple of typos in the first 2 seconds).

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net




Re: accepted by the compiler, rejected by the preprocessor!

2003-03-21 Thread Brendan Cully
On Friday, 21 March 2003 at 14:21, Paul Eggert wrote:

I've noted some typos in case you want to fix them.

> The next version of Autoconf will have some documentation about this.
> Here's the current draft, written by Akim Demaille, in Texinfo format:
> 
> 
> 
> @node Present But Cannot Be Compiled
> @section Header Present But Cannot Be Compiled
> 
> The most important guideline to bare in mind when checking for
  bear
> features is to mock as much as possible the intended use.
 mimic
> Unfortunately, old versions of @code{AC_CHECK_HEADER} and
> @code{AC_CHECK_HEADERS} failed to follow this idea, and used to call
  called
> the preprocessor, instead of the compiler, to check for headers.  As a
> result, incompatibilities between headers went unnoticed during
> configuration, and maintainers finally had to deal with this issue
> elsewhere.
> 
> Since Autoconf 2.56 both checks are performed, and @code{configure}
  As of
> complains loudly if the compiler and the preprocessor do not agree.
> For the time being the result is that of the preprocessor, so that
   ^used
> maintainers can adjust their @file{configure.ac}, but in the near
> future, the compiler only will be considered.
 ^only 





Re: accepted by the compiler, rejected by the preprocessor!

2003-03-21 Thread Paul Eggert
"Dr. David Kirkby" <[EMAIL PROTECTED]> writes:

> I'm not quite sure how a header file can be usable, but not present!!

The next version of Autoconf will have some documentation about this.
Here's the current draft, written by Akim Demaille, in Texinfo format:



@node Present But Cannot Be Compiled
@section Header Present But Cannot Be Compiled

The most important guideline to bare in mind when checking for
features is to mock as much as possible the intended use.
Unfortunately, old versions of @code{AC_CHECK_HEADER} and
@code{AC_CHECK_HEADERS} failed to follow this idea, and used to call
the preprocessor, instead of the compiler, to check for headers.  As a
result, incompatibilities between headers went unnoticed during
configuration, and maintainers finally had to deal with this issue
elsewhere.

Since Autoconf 2.56 both checks are performed, and @code{configure}
complains loudly if the compiler and the preprocessor do not agree.
For the time being the result is that of the preprocessor, so that
maintainers can adjust their @file{configure.ac}, but in the near
future, the compiler only will be considered.

Consider the following example:

@example
$ @kbd{cat number.h}
typedef int number;
$ @kbd{cat pi.h}
const number pi = 3;
$ @kbd{cat configure.ac}
AC_INIT
AC_CHECK_HEADERS(pi.h)
$ @kbd{autoconf -Wall}
$ @kbd{./configure}
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking pi.h usability... no
checking pi.h presence... yes
configure: WARNING: pi.h: present but cannot be compiled
configure: WARNING: pi.h: check for missing prerequisite headers?
configure: WARNING: pi.h: proceeding with the preprocessor's result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to bug-autoconf@@gnu.org. ##
configure: WARNING: ##  ##
checking for pi.h... yes
@end example

@noindent
The proper way the handle this case is using the fourth argument
(@pxref{Generic Headers}):

@example
$ @kbd{cat configure.ac}
AC_INIT
AC_CHECK_HEADERS(number.h pi.h,,,
[[#if HAVE_NUMBER_H
# include 
#endif
]])
$ @kbd{autoconf -Wall}
$ @kbd{./configure}
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for number.h... yes
checking for pi.h... yes
@end example