config.h (was Re: Misc. consequences of backend memory management changes)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I'd find it convenient if we could eventually create config.h.in
> automatically from configure.in with autoheader, but in order to do that
> configure needs to know about everything that's going on in there. It's
> not nice to invite your users to edit header files anyway...

I looked at autoheader and it strikes me as yet another glorified
'cat'. If we used it, we'd basically have an acconfig.h that contains
exactly what's now in the handgenerated config.h.in, and autoheader
would copy it all to config.h.in.

If we had a bunch of config.h.in's that could share code, this might
be useful, but for our present purposes I'm missing where the win is.

One thing that does occur to me is that a very large fraction of
config.h is now symbols that are supposed to be set by configure,
and as you say it's not good to give people the idea that they
should tweak those results by hand after configuring. What do you
think of pulling the remaining hand-settable symbols out into a
separate file, maybe called something like "siteconfig.h"? Then
config.h becomes purely a machine-generated file. This would
also solve the problem of losing hand-set config choices if you
rerun configure.

regards, tom lane