Robert Haas <robertmhaas@gmail.com> writes:
> 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:
Don't we have more or less that already in src/tools/pginclude/cpluspluscheck?
> 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.
I do not think that pgrminclude will *ever* be something that can be
quasi-automatic or work without close adult supervision. In the
first place, whether a given reference is required or not can easily
vary depending on platform and compile options. In the second place,
when there is something removable it's often because there are multiple
inclusion pathways reaching the same header file, and figuring out
which one is most appropriate to keep is a judgment call that requires
some understanding of what we think the system structure ought to be.
In fact, undoing the mess that the last pgrminclude run created was
sufficiently painful that I'm not sure I want to see it run again ever.
A few unnecessary includes isn't that big a problem.
Having said that, part of the reason for the carnage was that someone
had previously created a circular #include loop. It would be good to
have a tool that would whine about that; or at least fix pgrminclude
so it would refuse to do anything if it found one.
regards, tom lane
