Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> Yeah. Even if this could be made to work well, we'd still have to do
>> something like get an absolute consensus from all build farm animals,
>> if we expected to have an absolutely trustworthy list. I don't think
>> pgrminclude is a bad idea. I just think that it should only be used to
>> guide the efforts of a human to remove superfluous #includes, which is
>> how it is used anyway.
> I actually think we'd probably be better off running pgrminclude once
> per release cycle rather than any less often.
If it were more automatic and less prone to give bogus answers, I could
get behind that ... but as is, I'd frankly be happier if we *never* ran
it. It took quite a lot of effort to dig out from under the mess it
made last time, and I don't recall that we have ever had a run that
was entirely trouble-free.
Now, a contributing factor to the most recent mess was that somebody had
created circular header #include's; maybe it would help if the thing
were programmed to notice that and punt, rather than doing its best to
wind the ball of string even tighter. In general, though, any
recommendation from the tool to remove #includes in headers, as opposed
to consumer .c files, needs to be taken with about ten grains of salt.
The other serious problem, as Peter notes, is that there are inclusions
that are only needed on particular platforms or with particular build
options. AFAIK, Bruce's current methodology for running pgrminclude
takes no account of that.
regards, tom lane
