On Tue, Aug 11, 2009 at 9:56 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Given that the anum.h stuff is gone, "vastly" might be an >> overstatement. I'm pretty surprised to find out that people don't >> like the idea of having dependencies be correct from anywhere in the >> tree. Even if I'm the only developer who does partial builds, the >> cost seems to me to be next to nil, so I'm not quite sure what anyone >> gets out of rejecting this patch. > > It's not that having the dependencies be 100% up to date wouldn't be > nice; it's that there's a limit to how much we're willing to uglify > the Makefiles to have that. The makefiles need maintenance too, > you know, and putting things far away from where they should be is > not any better in the makefiles than it is in C code.
Well, I certainly agree that making a huge mess to address what is admittedly a corner case is not a good idea. But I also don't think this patch is all that messy. However, I guess we're getting to the point where we need to make a decision one way or the other so that we can close out this CommitFest. > As far as I can tell, if you've used --enable-depend then things will > get updated properly before you can ever attempt to run the code > (ie, install a rebuilt postmaster). The only situation where you'd > actually get an improvement from redoing the dependencies like this > is where lack of an update to a derived file results in a compiler > error/warning. But there aren't many such cases. The only one I can > even think of offhand is lack of an fmgroids.h symbol for a newly-added > function ... but we don't use F_XXX symbols enough to make that a > convincing example. We've intentionally arranged things so that > more-fragile cases like gram.h are not referenced outside their own > directories. Yes, that's definitely the best situation. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
