git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/5] Header includes cleanup

From
Christian Couder <chriscool@tuxfamily.org>
Date
Mar 31, 2009, 05:53 UTC
Message-ID
<200903310753.11595.chriscool@tuxfamily.org>
In-Reply-To
<49D0A3DF.4000203@viscovery.net>
Le lundi 30 mars 2009, Johannes Sixt a écrit :
Show 19 quoted lines
> 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.

Previous: Christian Couder
Message 17 of 17 in “Header includes cleanup”
  1. 0/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  2. 1/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  3. 2/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  4. 3/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  5. 4/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  6. 5/5 Header includes cleanupNathaniel P Dawson, Mar 30, 2009
  7. Johannes SixtMar 30, 2009
  8. Nathaniel P DawsonMar 30, 2009
  9. Christian CouderMar 31, 2009
  10. Junio C HamanoMar 31, 2009
  11. Christian CouderApr 2, 2009
  12. Junio C HamanoApr 2, 2009
  13. Jeff KingApr 2, 2009
  14. Christian CouderApr 3, 2009
  15. Jeff KingApr 3, 2009
  16. Christian CouderApr 3, 2009
  17. Christian CouderMar 31, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.