Amit's complaint about unnecessary headers got me thinking about
src/tools/pginclude. I think the the stuff in this directory is
trying to do something useful, because I think extra #include
directives that we don't need are a useful thing to eliminate.
However, in practice the contents are very hard for anybody to use
except maybe Bruce, who wrote it with his own environment in mind. On
my system, any attempt to rerun pgcompinclude -- which is described as
a prerequisite to running pgrminclude -- produces enormous numbers of
bogus errors and warnings, both because of the attempt to call every
defined macro with made-up arguments and because I configure with
stuff like --with-includes=/opt/local/include which pgcompinclude
knows nothing about.
I wonder if we can do better. The attached patch is the rest of a
couple of hours of hacking on a "see whether all of our includes
compile separately" project. Directions:
1. configure
2. go to src/tools/pginclude
3. make test-compile-include
It strikes me that if we could make this robust enough to include in
the buidlfarm, that would be good. And maybe we could then have a
pgrminclude tool which is a bit smarter also, and something that
anyone can easily run. I don't think pgrminclude should be part of
the buildfarm, but being able to run it every release cycle with
relatively minimal pain instead of every 5 years with extensive
fallout seems like it would be a win.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
