Re: what if i use makeheader tool to generate c header file, it would be accepted.

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Sep 19 2022, Skrab Sah wrote:

Just sending a $subject is rather light on details, so I'm having to do
a lot of guessing, but here goes.

In case this is a genuine "prep question" that you're asking in
wonderining if you should even waste time on coming up with a patch to
do $subject I want to say that:

- Yes, this project would definitely be interested in the general topic
  of "fixing our headers". E.g. as I noted in passing in [1] (and this
  is just a case I happen to remember) we have obviously "bad" cases of
  headers being included when they don't need to that e.g. the iwyu tool
  spots.

- I think it's *very unlikely* that a patch that just drops in some
  external tool to generale a bunch of our code or headers would be
  accepted without a very strong case being made for its advantages.

Now, this does *not* mean that we're not interested, but just that we're
very big on a "show your work" approach to things.

So I'd think that you'd want to pursue a more incremental approach,
e.g. are there cases that makeheader spots now that can be looked at and
turned into patches? Can we perhaps get to a point whene we can run
"makeheader" in CI and spot changes that make header definitions
obsolete?

I think you'd also want to look at some prior art in this
area. E.g. COMPUTE_HEADER_DEPENDENCIES is something we use to get a
"perfect" dependency graph of headers right now.

I'm not sure how that overlaps with the makeheader use-case, but any
patches in the area should aim to review related existing work & tools,
and how a new tool is better, or fills in previous blind-spots.

For those trying to follow-along, this is the documentation for the
"makeheaders" program (which I've only skimmed, and I haven't yet used
the tool): https://fossil-scm.org/home/doc/trunk/tools/makeheaders.html

I think the biggest problem with our headers is not that we over-do
interface definitions sometimes, or that we miss some includes, but that
most things genuinely end up depending on git-compat-util.h, and
cache.h. The latter of those is a big bag of random unrelated
functions. It would be nice to split it up, so that if you e.g. need to
change just one function in cache.h we don't need to re-build the entire
project.

But that "biggest problem" isn't so big, it's only something people
working on git find occasionally annoying, and ccache mostly mitigates
it...

1. https://lore.kernel.org/git/220825.86a67s4e6r.gmgdl@evledraar.gmail.com/