Re: dependencies for generated header files

Robert Haas <robertmhaas(at)gmail(dot)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.

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.

regards, tom lane