[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of config.h: summary of responses.
From: |
Ian Lance Taylor |
Subject: |
Re: Use of config.h: summary of responses. |
Date: |
06 Jan 2005 21:52:25 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
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
- Re: Use of config.h: summary of responses.,
Ian Lance Taylor <=