Tom Lane writes:
> Another bug report complaining of include file name conflicts came in
> just now. The only solution I can see is to rename config.h to
> something more project-specific. Should we do this, or keep ignoring
> the problem?
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.
What I would envision is this:
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.)
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.
3. The "internal" headers are installed in a subdirectory of $includedir
which is clearly named, such as .../include/postgresql-internal, possibly
with a version number in there. Users that want to build backend modules
explicitly need to ask for those things with an -I compile flag. At the
same time, those users would be forced to accept our config.h as gospel,
which is probably a good thing. (If we're still hearing complaints we can
ponder renaming it again.)
This scheme would also give a clear separation between platform-dependent
and platform-independent header sets, which would please "power
installers" very much.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter