On Mon, 13 Sep 2004, Ralf Corsepius wrote:
On Mon, 2004-09-13 at 17:20, Bob Friesenhahn wrote:
Yes, but this is not what current autoconf's autoheaders are about.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'.
Right, autoconf/autoheader will generate a "config.h" which grows ever larger as autoconf (and the application's configure script) becomes
more sophisticated.
As for myself, I find that installing a trimmed-down configuration header which only includes the definitions required for the headers to work correctly is the best choice.I have found myself in the same boat, but, and this might be a surprize to you: Such config-headers in most cases boil down to very few defines, which very easily can be encoded into very simple configure-script fragments.
My package installs a "config.h" with only 4 #defines. Only one of these is an Autoconf #define. The "config.h" which is installed is produced by the second argument of AC_CONFIG_HEADERS and is based on a hand-maintained "config.h.in".
If Autconf's AC_DEFINE macro was extended to support it, an option flag could be passed which allows autoheader to maintain a secondary "config.h" file containing only definitions marked as necessary to export in the installed headers. These could be automatically name-prefixed if so desired.
Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx http://www.simplesystems.org/users/bfriesen
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
