git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Skrab Sah <skrab.sah@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@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: Sat, 24 Sep 2022 13:49:47 +0530	[thread overview]
Message-ID: <CA+J78MV2tanEUNBOdWdQ6xmXBoDnKzerox6GAvzDU+V5V0MHFA@mail.gmail.com> (raw)
In-Reply-To: <220923.861qs25yr8.gmgdl@evledraar.gmail.com>

https://github.com/git/git/pull/1344

help me in solving this.
my spec, debian x86_64.

On Fri, 23 Sept 2022 at 13:05, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Wed, Sep 21 2022, Skrab Sah wrote:
>
> > [...]
> > Is Makefile generated by another script?
> > [...]
> > For patches, I need some time and your help.
>
> Aside from what Junio noted in another reply: I and others here are
> generally happy to help, but when you're proposing to entirely re-do how
> a part of our build process works, then you really should know the
> answers to not only the basics ("is the Makefile generated?"), but also
> the more complex interactions.
>
> If you're still interested I think there's good things to work on in
> this area, but starting smaller (e.g. my upthread iwyu suggestion, or
> similar) would be much better.
>
> I.e. think about the practical benefits of a proposed big rewrite are,
> and whether there's ways to get some large portion of that in easier
> ways.
>
> > On Tue, 20 Sept 2022 at 15:43, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> >>
> >>
> >> 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.
>

  reply	other threads:[~2022-09-24  8:22 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
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 [this message]
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=CA+J78MV2tanEUNBOdWdQ6xmXBoDnKzerox6GAvzDU+V5V0MHFA@mail.gmail.com \
    --to=skrab.sah@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).