Re: [PATCH 0/5] Header includes cleanup

[Christian Couder <chriscool@tuxfamily.org>]

Le lundi 30 mars 2009, Johannes Sixt a écrit :
> Please wrap your lines at ca. 75 columns.
>
> Nathaniel P Dawson schrieb:
> > This is just the beginning for this project. I'm slowly cleaning up
> > the header includes one chunk at a time. I hope my patches aren't too
> > messy, I've learned how to better utilize git to make patches and
> > organize my commits logically so I'll submit neater chunks henceforth.
> > You can expect patches from me nightly until I've finished this
> > project.
>
> You have removed includes that are implied by other includes, i.e. if
> foo.h includes bar.h, then you removed #include "bar.h" from *.c if there
> is #include "foo.h".
>
> IMO, this is not a good guiding principle to reduce includes. A better
> principle is to keep #include "bar.h" in a source or header file iff a
> feature that is declared or defined in bar.h is *used* *directly* in that
> source or header file, regardless of whether bar.h is included in foo.h
> that is itself included in that source or header file.

In theory, it's perhaps the best way to do it. But we don't do that for 
system header includes. And I think it makes it very difficult to cleanup 
header includes, because you have to check what is needed for each feature 
in a file. So I think we have to choose between basically no header include 
cleanup or a cleanup like the one Nathaniel started.

> If this latter principle is obeyed, then the build won't break by
> removing the include of foo.h (for the reason that nothing of foo.h is
> *use* *directly* anymore).

I think it's more likely that we will add features rather than remove some.
And it's not very difficult if we remove some, to remove "foo.h" and 
add "bar.h" at the same time.

For example, many files include "cache.h", does it really make sense to try 
to remove these #include because we could replace them by only includes 
of "git-compat-util.h" and "hash.h"? I don't think so.

Best regards,
Christian.