Re: Removing useless #include's.

Hello.

At Thu, 15 Feb 2018 11:12:05 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in <6748.1518711125@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > While looking some patch, just from curiosity, I checked for
> > redundant #include's in the source tree (except
> > contrib). "redundant" here means that a file is included in
> > another include file nearby.
> 
> > I found 641 includes that is just removable with no side effect
> > with two exceptions.
> 
> I tend to be a bit suspicious of this sort of thing, especially for
> old files that have been through previous rounds of "unnecessary
> include" removal.  It's usually a good idea to ask *why* is a header
> no longer needed?  The answer, usually, is that somebody added the
> same #include to some other header, and it's not uncommon for that
> to have been a bad idea.  It's usually best to minimize cross-header
> inclusions, IMV, and it's always necessary to exercise judgment
> when adding one.

As another point of view, placing an #include just because the
source file uses the definition in the file is also
reasonable. Header files are kept not to have a problem when
included multiple times. I don't surprise if someone says that
this is rather harmful. And I'm glas to read the clear reason.

> We've also had more than a few problems with automatic scripts deciding
> that an #include could be removed because they weren't testing with the
> combination of build options that made it necessary.
> 
> See for instance commits 6416a82a6 through 1609797c2 for some history
> of poorly managed #include removal.

I'm surprised to find no circular/mutual dependency even nor
multilevel inclusion among header files. I think I understand the
reason.

In this patch, I didn't touch the header files since I felt that
somewhat dangerous. But anyway I understand doing all of this at
a time can be dangerous.

Thank you for the suggestion, Tom.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center