From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Skrab Sah <skrab.sah@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: what if i use makeheader tool to generate c header file, it would be accepted.
Date: Tue, 20 Sep 2022 11:58:51 +0200 [thread overview]
Message-ID: <220920.86illi5p6w.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CA+J78MWvOEbJY6+NcLFn0SJGMZn=N7QUMwc=Bta+uHicvD892w@mail.gmail.com>
On Tue, Sep 20 2022, Skrab Sah wrote:
> Let me elaborate to you, how and why I wanted to implement the
> makeheaders tool in the project.
>
> First of all, this program will automatically generate c header(.h)
> files for specified c source(.c) files, which will help the developer.
>
> Here the test shows how the tool can be implemented in different
> cases: https://github.com/skrab-sah/makeheaders-test
>
>
> pros:
> 1. it will slightly reduce the size of the project.
> 2. no need to declare anything in the header file, which is time
> consuming and a headache for developers.
Sure, this all sound interesting in principle, and I think the answer is
definitely "we're not opposed in principle, but if you're interested
let's see patches".
But whether this is worthwhile is something that really can't be
answered until someone (i.e. you) puts in the legwork of implementing
it.
You'll then run into various trade-offs you'd have to make, and issues
you may not have forseen. Just some I can think of offhand:
* It's unclear if you mean that we'd commit the generated files or
not. If "not" then our Makefile will need to learn to do two-stage
compilation. I.e. we'd ship a copy of the makeheader tool, build
that, build the headers, and then do our "real" build.
I happen to have an implementation of that "two-stage" compilation
for entirely different reasons (being able to do configure/probes for
our compilation), but *just* doing that is non-trivial.
* The way we document various APIs now is via manually curated header
files, e.g. how would a strbuf.h look like in this model you're
proposing?
Obviously we could move those comments to the *.c file, but right now
we have a convention of implementation comments going in the *.c
file, but the API docs going in the *.h.
We could tell them apart with "/*" v.s. "/**" comments, as we do
now. But part of the point of having them in the *.h file is that you
can easily skim the docs & APi definition. Putting the docs in the
much bigger *.c file wouldn't be nice.
* We'd have another not-quite-compiler C-parser running on git.git,
right now we basically have a dependency on spatch's parsing. See
5cf88fd8b05 (git-compat-util.h: use "UNUSED", not "UNUSED(var)",
2022-08-25).
Is this parser smart enough to handle all the edge cases? E.g. for
KHASH_INIT() we define interfaces via a macro-indirection, so an
auto-generated *.h needs to resolve the macros in the *.c file.
next prev parent reply other threads:[~2022-09-20 10:14 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
2022-09-19 17:40 ` Junio C Hamano
2022-09-20 8:40 ` Skrab Sah
2022-09-20 9:58 ` Ævar Arnfjörð Bjarmason [this message]
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=220920.86illi5p6w.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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).