Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
