Thread: Autoheader plan

I want to make pg_config.h.in be automatically generated by autoheader
so we don't have to edit it by hand, but there is a lot of stuff in
pg_config.h.in that isn't directly generated by configure, so it needs
to be moved elsewhere.

Here's what I want to do:

Move DEF_NBUFFERS and DEF_MAXBACKENDS to the header files where
NBuffers and MaxBackends are declared.  Remove --with-maxbackends
configure option.  There's no need for users to edit these at compile
time.

All of the remaining code from "part 2" of the existing pg_config.h.in
will be moved to a separate file (maybe pg_config_manual.h?) and will
be unaffected by autoheader and configure.

Everything in part 1 and 3 can be automatically generated.

Move inclusion of pg_config_os.h to c.h.  That means c.h will contain
the following code near the top:

#include pg_config.h
#include pg_config_manual.h
#include pg_config_os.h

(Perhaps the first one should be renamed to pg_config_auto.h for
parallelism?)

All code in part 5 will be moved to c.h section 8, which contains
similar code already anyway.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> I want to make pg_config.h.in be automatically generated by autoheader
> so we don't have to edit it by hand, but there is a lot of stuff in
> pg_config.h.in that isn't directly generated by configure, so it needs
> to be moved elsewhere.

Maybe I'm just a Luddite, but I've never understood what autoheader
buys us that's worth the trouble of conforming to its restrictions.
Why should we bother?

(The specifics of your plan are fine if we accept the premise that we
should use autoheader, but I'm not sold on the premise...)
        regards, tom lane

Tom Lane writes:

> Maybe I'm just a Luddite, but I've never understood what autoheader
> buys us that's worth the trouble of conforming to its restrictions.

We wouldn't have to edit the config.h file by hand whenever some editing
of configure.in occurs.  That's all, but I'm not aware of any real
restrictions that that would impose.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Maybe I'm just a Luddite, but I've never understood what autoheader
>> buys us that's worth the trouble of conforming to its restrictions.

> We wouldn't have to edit the config.h file by hand whenever some editing
> of configure.in occurs.  That's all, but I'm not aware of any real
> restrictions that that would impose.

Mph.  Well, there is some advantage in separating the manually-settable
config options from the automatically set ones (don't have to worry
about whether to edit config.h.in or config.h), so your plan is probably
a good idea in any case.
        regards, tom lane