Tom Lane wrote:
> Clean up the #include mess a little.
>
> walsender.h should depend on xlog.h, not vice versa. (Actually, the
> inclusion was circular until a couple hours ago, which was even sillier;
> but Bruce broke it in the expedient rather than logically correct
> direction.) Because of that poor decision, plus blind application of
> pgrminclude, we had a situation where half the system was depending on
> xlog.h to include such unrelated stuff as array.h and guc.h. Clean up
> the header inclusion, and manually revert a lot of what pgrminclude had
> done so things build again.
>
> This episode reinforces my feeling that pgrminclude should not be run
> without adult supervision. Inclusion changes in header files in particular
> need to be reviewed with great care. More generally, it'd be good if we
> had a clearer notion of module layering to dictate which headers can sanely
> include which others ... but that's a big task for another day.
What pgrminclude does it to lock down the minimal set of includes, and
that easily could cause something like xlog.h becoming the go-to include
file for many C files. I don't remember this problem happening before
but it clearly happened this time.
Not sure how to avoid that except, as you said, analyze the entire
changeset of pgrminclude. For this run, I focused on not breaking any
platform builds so I was not focusing on the actual include file layout.
I assumed fiddling with the actual pgrminclude output would likely break
builds.
The process I used was to get pgcompinclude to allow all include files
to compile (so they their inclusion would not bleed into files that
included them), then run pgrminclude.
Well, I assume we are done for another five years. The includes removed
were minimal, especially considering five years of work.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
