|
From: | Guido Draheim |
Subject: | Re: problem with AC_CONFIG_HEADERS and automake |
Date: | Sat, 03 May 2003 16:58:25 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.1) Gecko/20020826 |
Installing config.h (with its non-prefixed defines) can lead to problems later on, of course. Putting in guards does sometimes not do the right thing either, as prepackaged software might be build on different hosts with different configurations leading to different configure`d defines. That is in one installed config.h the define is ON will in the other it is OFF, the guard define will make that unconditionally ON. Better put a prefix in there, so that symbols are easily classified to be the configuration of your lib and not from anyone's else library header. The macro AX_PREFIX_CONFIG_H might help you here, and it does not even require you to write your own header.h.in, plus all defines are guarded as an extra benefit for you. The only problem might be that your installed header files (and only these) need to be corrected to be dependent in its ifdef#d on the prefixed symbols. That's been discussed multiple times on the automake and autoconf mailinglists. have fun, guido http://ac-archive.sf.net Dale E Martin schrieb:
I have some #defines I need defined based off of the results of configure tests. I was using AM_CONFIG_HEADER to do this, but it doesn't have cpp guards and I needed these values in installed headers, so I looked for another solution. I ended up writing my own header.h.in files with cpp guards, and used AC_CONFIG_HEADERS to write out the #defines of interest based on the configure tests. So far, so good, it all works great with automake 1.7. On automake 1.5, however, I have the problem that automake complains that I should use "AM_CONFIG_HEADER", not "AC_CONFIG_HEADER" (note the lack of the S). Is there some workaround for this problem that is compatible with automake 1.5 and 1.7? Thanks, Dale
[Prev in Thread] | Current Thread | [Next in Thread] |