Re: dependencies for generated header files

On Tue, Aug 11, 2009 at 9:56 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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