Re: Rename config.h to pg_config.h?

Peter Eisentraut <peter_e@gmx.net> writes:
> Another problem in all of this is that even if you hide the config.h
> sufficiently, you'll end up including it anyway of course, and more likely
> than not you will have a symbol clash with what the user wants to define
> in his config.h file.

This is true in theory, but in practice we've not seen very many
complaints about it; perhaps that's because there's a fair amount of
standardization of Autoconf usage.  (HAVE_FOO_H probably gets set the
same way by every package that might use it, for example.)  We have
seen the "#include config.h gets the wrong thing" problem complained
of repeatedly, though.

> 1. Make all headers that are installed by default (client side) not use
> config.h.  This is mostly a problem with libpq++.h, but surely this
> problem was solved somewhere before.  (Worst case, we'll preprocess the
> file ourselves.)

I think we would indeed have to preprocess the files ourselves, and it
seems like a lot of work compared to the size of the problem.

> 2. Then we can install the above set of headers directly into $includedir
> (e.g., /usr/include), since they're relatively clearly named.  This has
> been one of my pet peeves: right now we are forced to install in a
> subdirectory of /usr[/local]/include because of this conflict, which
> requires plain-old libpq programs to add an explicit -I compile flag,
> which is not nice.

Wouldn't renaming config.h be sufficient to accomplish that?

> This scheme would also give a clear separation between platform-dependent
> and platform-independent header sets, which would please "power
> installers" very much.

But wouldn't the preprocessed client header files have to be regarded as
platform-dependent?  I don't see how this restructuring improves matters
in that regard.

The bottom line for me is that renaming config.h would accomplish quite
a bit for a very small amount of work.  I'm willing to get it done,
whereas I'm not willing to take on the above-described project any time
soon.  What are your prospects for time to get the more complete
solution in place?
        regards, tom lane