Re: [PATCH 0/5] Header includes cleanup

From: Christian Couder <chriscool@tuxfamily.org>
Date: Apr 3, 2009, 04:14 UTC
Message-ID: <200904030614.26310.chriscool@tuxfamily.org>
In-Reply-To: <20090402112705.GD14599@sigill.intra.peff.net>

Hi,

Le jeudi 2 avril 2009, Jeff King a écrit :

Show 19 quoted lines

> On Wed, Apr 01, 2009 at 10:25:09PM -0700, Junio C Hamano wrote:
> > > - a header file should be included in a C file only if it is needed
> > > to compile the C file (it is not ok to include it only because it
> > > includes many other headers that are needed)
> >
> > If that is the rule, perhaps the problem lies not in a .c program that
> > includes such a .h header, but in the .h itself that includes many
> > other header files.
>
> If this were combined with splitting gigantic .h files (like cache.h)
> into smaller logical units, then we could in theory speed up
> recompilation times with make (we would also need to correctly track
> header dependencies, but gcc -M can do this fairly easily).
>
> But it does come at the price of actually having to consider which
> include files are necessary. I can't think of more than half a dozen
> times in the last year I have actually had to add a #include while
> working on a git .c file, mostly because everything and the kitchen sink
> is included by cache.h.

Yeah, I think the best feature of the actual design is the simplicity, and that's why we don't have to add new #include very often. So let's keep this simplicity by having and applying rules to keep things simple for the developer.

> So I don't know if it is worth it.

I am not sure what you are talking about here, but if you mean that you don't think it's worth splitting gigantic .h files (like cache.h) into smaller logical units, then I agree.

Best regards, Christian.