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

>
>
> 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.
>