Robert Haas <robertmh...@gmail.com> writes: > On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan <pe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers