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