Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Clean up the #include mess a little.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
Date: 2011-09-05 13:52:45
Message-ID: 201109051352.p85Dqj918790@momjian.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2011-09-05 13:55:58
Subject: Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
Previous:From: Bruce MomjianDate: 2011-09-05 13:45:09
Subject: Re: Re: [COMMITTERS] pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge

pgsql-committers by date

Next:From: Greg StarkDate: 2011-09-05 13:55:58
Subject: Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
Previous:From: Bruce MomjianDate: 2011-09-05 13:45:09
Subject: Re: Re: [COMMITTERS] pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group