Re: Use of config.h: summary of responses.

[Ian Lance Taylor]

Bob Friesenhahn <address@hidden> writes:

> The fact of the matter is that some/many libraries have header files
> which are OS/CPU/compiler dependent and there has to be a way to
> record/work-around these dependencies so that the library headers work
> right.  This way is commonly known as 'config.h'.

Take a look at how BFD handles bfd.h.

There are only a few autoconf-like issues which really matter for
typical installed header files.  For example, all BFD really cares
about that it needs from autoconf is the name of a 64-bit type.  To
handle this, we get autoconf to define a few relevant macros.  Then we
substitute in bfd-in2.h as we do in config.h, by adding it to
AC_CONFIG_FILES.  Then we install the result.

This is not 100% reliable if you change compilers, particularly if you
go from gcc to non-gcc on a 32-bit platform.  But it's quite reliable
in practice.

The point is, autoconf does give you the basic tool you need: adding
files to AC_CONFIG_FILES.  What it doesn't give you is the information
you need to do that in a portable manner.

Ian