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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
