git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Skrab Sah <skrab.sah@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: what if i use makeheader tool to generate c header file, it would be accepted.
Date: Mon, 19 Sep 2022 12:45:06 +0200	[thread overview]
Message-ID: <220919.86zgev635z.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CA+J78MWhp3qmbBhhSoioJP+d5eh-iEd_vHZdTNB69o7EvvXWYQ@mail.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/

  reply	other threads:[~2022-09-19 11:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  7:14 what if i use makeheader tool to generate c header file, it would be accepted Skrab Sah
2022-09-19 10:45 ` Ævar Arnfjörð Bjarmason [this message]
2022-09-19 17:40   ` Junio C Hamano
2022-09-20  8:40     ` Skrab Sah
2022-09-20  9:58       ` Ævar Arnfjörð Bjarmason
2022-09-21  7:53         ` Skrab Sah
2022-09-21  8:11           ` Đoàn Trần Công Danh
2022-09-21  8:46             ` Skrab Sah
2022-09-23  7:28           ` Ævar Arnfjörð Bjarmason
2022-09-24  8:19             ` Skrab Sah
2022-09-21 16:28       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220919.86zgev635z.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=skrab.sah@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).