Message ID | pull.1525.git.1683431149.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Header cleanups (final splitting of cache.h, and some splitting of other headers) | expand |
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > hash-ll, hashmap: move oidhash() to hash-ll > fsmonitor-ll.h: split this header out of fsmonitor.h If you are introducing a bunch of -ll suffixed files, wouldn't you want to either rename them to ll- prefixed, or rename ll-merge to match them to make things consistent?
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > Maintainer notes: (1) This series is built on top of a merge of > en/header-split-cache-h-part-2 into master, (2) This series has no conflicts > with next, but has three simple & small conflicts with seen: > > * a textual conflict with tl/notes-separator (affecting builtin/notes.c; to > address, nuke the conflict region and add an include of alloc.h after > builtin.h) > * a textual & semantic conflict with cw/strbuf-cleanup (affecting strbuf.c; > to address, delete the conflict region and also delete the include of > repository.h) > * a semantic conflict with rn/sparse-diff-index (affecting > builtin/diff-index.c; to address, add an include of sparse-index.h). After looking at them myself, I think that the above resolution makes sense. > This series continues to focus on splitting declarations from cache.h to > separate headers, and also cleans up some other small header issues. By > patch 16, cache.h is gone. It is a nice touch to update the part of the coding guidelines document that names which header files other than <git-compat-util.h> can be the first one to include.
On Mon, May 8, 2023 at 8:29 AM Junio C Hamano <gitster@pobox.com> wrote: > > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > hash-ll, hashmap: move oidhash() to hash-ll > > fsmonitor-ll.h: split this header out of fsmonitor.h > > If you are introducing a bunch of -ll suffixed files, wouldn't you > want to either rename them to ll- prefixed, or rename ll-merge to > match them to make things consistent? Sure, I'm happy to rename ll-merge to merge-ll. I prefer a suffix since it is common to see files sorted by filename (whether by Git or by the shell) and the suffix tends to keep similar-ish files together.
Elijah Newren <newren@gmail.com> writes: > Sure, I'm happy to rename ll-merge to merge-ll. I prefer a suffix > since it is common to see files sorted by filename (whether by Git or > by the shell) and the suffix tends to keep similar-ish files together. It can go both ways, though. Grouping lower-level things together has values, too ;-). If foo and foo-lowleve needs to be grouped and read together to be understood, it is a sign that the conceptual separation between the higher- and lower-level things is not done cleanly enough. Having said that, I do not care too deeply either way, as long as it makes it easier to locate what we need to in the end result. Thanks.
> This series continues to focus on splitting declarations from cache.h to > separate headers, and also cleans up some other small header issues. By > patch 16, cache.h is gone. Congratulations on slaying the cache.h beast! Glad I was able to follow the entire series to see how many headers cache.h eventually splits up into. Most of the patches in this series LGTM, but I do have a higher level concern. A couple of patches in this series splits files from foo.h to foo-ll.h and foo.h with the goal of having other files only include foo-ll.h when needed and not foo.h which has other unnecessary includes. While I believe that having less unnecessary includes clarifies which files have what dependencies, I also believe that we are missing documentation for how new functions should be added to either foo.h or foo-ll.h. What criteria are we using to separate out those functions?
On Thu, May 11, 2023 at 10:42 AM Calvin Wan <calvinwan@google.com> wrote: > > > This series continues to focus on splitting declarations from cache.h to > > separate headers, and also cleans up some other small header issues. By > > patch 16, cache.h is gone. > > Congratulations on slaying the cache.h beast! Glad I was able to follow > the entire series to see how many headers cache.h eventually splits up > into. Thanks. :-) > Most of the patches in this series LGTM, but I do have a higher level > concern. A couple of patches in this series splits files from foo.h to > foo-ll.h and foo.h with the goal of having other files only include > foo-ll.h when needed and not foo.h which has other unnecessary includes. > While I believe that having less unnecessary includes clarifies which > files have what dependencies, I also believe that we are missing > documentation for how new functions should be added to either foo.h or > foo-ll.h. What criteria are we using to separate out those functions? Right now it's a bit loose, and focused around structs rather than functions and function declarations. I'd state the guidelines roughly as: * The foo-ll.h variants should only #include whatever headers are necessary for the common structs they contain to be well-defined * The foo.h variants should take things (particularly inline functions) that require additional includes * We should prefer forward declaring structs rather than #include'ing a header where we can (though that's a bunch of patches in a follow-on series I've prepared) This is even a bit murky because of my use of the word "common". For example, I kept odb_path_map out of object-store-ll.h and left it in object-store.h, because there were only 2 files that used struct odb_path_map, while there are 56 that use the structs in object-store-ll.h, and the declaration of odb_path_map requires multiple extra headers. Now, you specifically asked about where function declarations and functions should go, and I side-stepped that question. In part, I'm leaving that undefined precisely because I was focused only on header cleanups and not source cleanups, and I suspect that diving into the code will yield insights about where we want to fit the boundary for those. So, for the many function declarations that could go in either header and satisfy all the above rules, I think the libification work you and Glen are doing is likely to nail this down a bit more. Once we have rules for how to divide those up, or even just a few examples that we have good arguments for, then we can happily start moving the function declarations between these headers. Does that sound fair?