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
