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

[Bob Friesenhahn]

On Mon, 13 Sep 2004, Ralf Corsepius wrote:

> On Mon, 2004-09-13 at 17:20, Bob Friesenhahn wrote:
>
> > 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'.
> Yes, but this is not what current autoconf's autoheaders are about.

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
address@hidden
http://www.simplesystems.org/users/bfriesen