{"thread":{"id":"58454","subject":"what if i use makeheader tool to generate c header file, it would be accepted.","startedAt":"2022-09-19T07:14:58Z","lastAt":"2022-09-24T08:21:40Z","messageCount":11,"participants":["Skrab Sah","Ævar Arnfjörð Bjarmason","Junio C Hamano","Đoàn Trần Công Danh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"463166","messageId":"CA+J78MWhp3qmbBhhSoioJP+d5eh-iEd_vHZdTNB69o7EvvXWYQ@mail.gmail.com","threadId":"58454","inReplyTo":null,"subject":"what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Skrab Sah","fromEmail":"skrab.sah@gmail.com","sentAt":"2022-09-19T07:14:42Z","receivedAt":"2022-09-19T07:14:58Z","isPatch":false,"sender":{"key":"skrab.sah@gmail.com","avatar":null},"body":"\n"},{"id":"463167","messageId":"220919.86zgev635z.gmgdl@evledraar.gmail.com","threadId":"58454","inReplyTo":"CA+J78MWhp3qmbBhhSoioJP+d5eh-iEd_vHZdTNB69o7EvvXWYQ@mail.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-19T10:45:06Z","receivedAt":"2022-09-19T11:00:58Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Sep 19 2022, Skrab Sah wrote:\n\nJust sending a $subject is rather light on details, so I'm having to do\na lot of guessing, but here goes.\n\nIn case this is a genuine \"prep question\" that you're asking in\nwonderining if you should even waste time on coming up with a patch to\ndo $subject I want to say that:\n\n- Yes, this project would definitely be interested in the general topic\n of \"fixing our headers\". E.g. as I noted in passing in [1] (and this\n is just a case I happen to remember) we have obviously \"bad\" cases of\n headers being included when they don't need to that e.g. the iwyu tool\n spots.\n\n- I think it's *very unlikely* that a patch that just drops in some\n external tool to generale a bunch of our code or headers would be\n accepted without a very strong case being made for its advantages.\n\nNow, this does *not* mean that we're not interested, but just that we're\nvery big on a \"show your work\" approach to things.\n\nSo I'd think that you'd want to pursue a more incremental approach,\ne.g. are there cases that makeheader spots now that can be looked at and\nturned into patches? Can we perhaps get to a point whene we can run\n\"makeheader\" in CI and spot changes that make header definitions\nobsolete?\n\nI think you'd also want to look at some prior art in this\narea. E.g. COMPUTE_HEADER_DEPENDENCIES is something we use to get a\n\"perfect\" dependency graph of headers right now.\n\nI'm not sure how that overlaps with the makeheader use-case, but any\npatches in the area should aim to review related existing work & tools,\nand how a new tool is better, or fills in previous blind-spots.\n\nFor those trying to follow-along, this is the documentation for the\n\"makeheaders\" program (which I've only skimmed, and I haven't yet used\nthe tool): https://fossil-scm.org/home/doc/trunk/tools/makeheaders.html\n\nI think the biggest problem with our headers is not that we over-do\ninterface definitions sometimes, or that we miss some includes, but that\nmost things genuinely end up depending on git-compat-util.h, and\ncache.h. The latter of those is a big bag of random unrelated\nfunctions. It would be nice to split it up, so that if you e.g. need to\nchange just one function in cache.h we don't need to re-build the entire\nproject.\n\nBut that \"biggest problem\" isn't so big, it's only something people\nworking on git find occasionally annoying, and ccache mostly mitigates\nit...\n\n1. https://lore.kernel.org/git/220825.86a67s4e6r.gmgdl@evledraar.gmail.com/\n"},{"id":"463203","messageId":"xmqqbkrbb6ua.fsf@gitster.g","threadId":"58454","inReplyTo":"220919.86zgev635z.gmgdl@evledraar.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-09-19T17:40:45Z","receivedAt":"2022-09-19T17:40:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Mon, Sep 19 2022, Skrab Sah wrote:\n>\n> Just sending a $subject is rather light on details, so I'm having to do\n> a lot of guessing, but here goes.\n> ...\n> In case this is a genuine \"prep question\" that you're asking in\n> wonderining if you should even waste time on coming up with a patch to\n> do $subject I want to say that:\n> ...\n> Now, this does *not* mean that we're not interested, but just that we're\n> very big on a \"show your work\" approach to things.\n\nPerhaps this should be made into a FAQ entry?\n\nIn general, we do not give promises or guidance, but something a\ncontributor finds it rewarding to work on, whether we would leter\naccept in the upstream, will spread among users and developers, and\neventually we would come begging to the contributor for upstreaming.\n\nOn the other hand, a new thing that the contributor who thought of\ndoes not feel it is worth investing their work in, if only to use\nfor themselves, is unlikely to be of interest to us.\n\nSo saying \"if this will be accepted, I'll work on it\" is counter\nproductive, as it is easily (mis)taken as a sign that it is the\nlatter case.\n\nIn other words, make it so good that we would come to you.\n\nThanks.\n\n"},{"id":"463293","messageId":"CA+J78MWvOEbJY6+NcLFn0SJGMZn=N7QUMwc=Bta+uHicvD892w@mail.gmail.com","threadId":"58454","inReplyTo":"xmqqbkrbb6ua.fsf@gitster.g","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Skrab Sah","fromEmail":"skrab.sah@gmail.com","sentAt":"2022-09-20T08:40:05Z","receivedAt":"2022-09-20T08:41:53Z","isPatch":false,"sender":{"key":"skrab.sah@gmail.com","avatar":null},"body":"Let me elaborate to you, how and why I wanted to implement the\nmakeheaders tool in the project.\n\nFirst of all, this program will automatically generate c header(.h)\nfiles for specified c source(.c) files, which will help the developer.\n\nHere the test shows how the tool can be implemented in different\ncases: https://github.com/skrab-sah/makeheaders-test\n\n\npros:\n 1. it will slightly reduce the size of the project.\n 2. no need to declare anything in the header file, which is time\nconsuming and a headache for developers.\n\nOn Mon, 19 Sept 2022 at 23:10, Junio C Hamano wrote:\n>\n> Ævar Arnfjörð Bjarmason writes:\n>\n> > On Mon, Sep 19 2022, Skrab Sah wrote:\n> >\n> > Just sending a $subject is rather light on details, so I'm having to do\n> > a lot of guessing, but here goes.\n> > ...\n> > In case this is a genuine \"prep question\" that you're asking in\n> > wonderining if you should even waste time on coming up with a patch to\n> > do $subject I want to say that:\n> > ...\n> > Now, this does *not* mean that we're not interested, but just that we're\n> > very big on a \"show your work\" approach to things.\n>\n> Perhaps this should be made into a FAQ entry?\n>\n> In general, we do not give promises or guidance, but something a\n> contributor finds it rewarding to work on, whether we would leter\n> accept in the upstream, will spread among users and developers, and\n> eventually we would come begging to the contributor for upstreaming.\n>\n> On the other hand, a new thing that the contributor who thought of\n> does not feel it is worth investing their work in, if only to use\n> for themselves, is unlikely to be of interest to us.\n>\n> So saying \"if this will be accepted, I'll work on it\" is counter\n> productive, as it is easily (mis)taken as a sign that it is the\n> latter case.\n>\n> In other words, make it so good that we would come to you.\n>\n> Thanks.\n>\n"},{"id":"463295","messageId":"220920.86illi5p6w.gmgdl@evledraar.gmail.com","threadId":"58454","inReplyTo":"CA+J78MWvOEbJY6+NcLFn0SJGMZn=N7QUMwc=Bta+uHicvD892w@mail.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-20T09:58:51Z","receivedAt":"2022-09-20T10:14:08Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Sep 20 2022, Skrab Sah wrote:\n\n> Let me elaborate to you, how and why I wanted to implement the\n> makeheaders tool in the project.\n>\n> First of all, this program will automatically generate c header(.h)\n> files for specified c source(.c) files, which will help the developer.\n>\n> Here the test shows how the tool can be implemented in different\n> cases: https://github.com/skrab-sah/makeheaders-test\n>\n>\n> pros:\n> 1. it will slightly reduce the size of the project.\n> 2. no need to declare anything in the header file, which is time\n> consuming and a headache for developers.\n\nSure, this all sound interesting in principle, and I think the answer is\ndefinitely \"we're not opposed in principle, but if you're interested\nlet's see patches\".\n\nBut whether this is worthwhile is something that really can't be\nanswered until someone (i.e. you) puts in the legwork of implementing\nit.\n\nYou'll then run into various trade-offs you'd have to make, and issues\nyou may not have forseen. Just some I can think of offhand:\n\n * It's unclear if you mean that we'd commit the generated files or\n not. If \"not\" then our Makefile will need to learn to do two-stage\n compilation. I.e. we'd ship a copy of the makeheader tool, build\n that, build the headers, and then do our \"real\" build.\n\n I happen to have an implementation of that \"two-stage\" compilation\n for entirely different reasons (being able to do configure/probes for\n our compilation), but *just* doing that is non-trivial.\n\n * The way we document various APIs now is via manually curated header\n files, e.g. how would a strbuf.h look like in this model you're\n proposing?\n\n Obviously we could move those comments to the *.c file, but right now\n we have a convention of implementation comments going in the *.c\n file, but the API docs going in the *.h.\n\n We could tell them apart with \"/*\" v.s. \"/**\" comments, as we do\n now. But part of the point of having them in the *.h file is that you\n can easily skim the docs & APi definition. Putting the docs in the\n much bigger *.c file wouldn't be nice.\n\n * We'd have another not-quite-compiler C-parser running on git.git,\n right now we basically have a dependency on spatch's parsing. See\n 5cf88fd8b05 (git-compat-util.h: use \"UNUSED\", not \"UNUSED(var)\",\n 2022-08-25).\n\n Is this parser smart enough to handle all the edge cases? E.g. for\n KHASH_INIT() we define interfaces via a macro-indirection, so an\n auto-generated *.h needs to resolve the macros in the *.c file.\n"},{"id":"463358","messageId":"CA+J78MUM=JiAF7R_8oV23OQ-LndJbRm4AUdPsgS4HT4SduFgiw@mail.gmail.com","threadId":"58454","inReplyTo":"220920.86illi5p6w.gmgdl@evledraar.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Skrab Sah","fromEmail":"skrab.sah@gmail.com","sentAt":"2022-09-21T07:53:11Z","receivedAt":"2022-09-21T07:53:35Z","isPatch":false,"sender":{"key":"skrab.sah@gmail.com","avatar":null},"body":"1. We would not commit the generated file.\n2. There are different ways we can install the makeheaders tool.\n3. Makefile will first generate the header file then other compilation.\n4. For API docs, there is one multi-line comment in the header file\nthat we can put in at the top of the .c file and also it will\nautomatically be copied in the .h file if we want.\n5. makeheaders tools is fast and small and it will not run always,\nonly when its respective file is changed.\n6. As I showed you before, we have different approaches to handle\ndifferent things so, it will be better to see in the patches.\n\nI think the patches will show you a better figure.\n\nfor patches, in makefile we need to add some script for the makeheaders tool.\nAnd the Makefile is too big and complicated to handle, it will consume time.\n\nIs Makefile generated by another script?\n\n\nFor patches, I need some time and your help.\n\nOn Tue, 20 Sept 2022 at 15:43, Ævar Arnfjörð Bjarmason wrote:\n>\n>\n> On Tue, Sep 20 2022, Skrab Sah wrote:\n>\n> > Let me elaborate to you, how and why I wanted to implement the\n> > makeheaders tool in the project.\n> >\n> > First of all, this program will automatically generate c header(.h)\n> > files for specified c source(.c) files, which will help the developer.\n> >\n> > Here the test shows how the tool can be implemented in different\n> > cases: https://github.com/skrab-sah/makeheaders-test\n> >\n> >\n> > pros:\n> > 1. it will slightly reduce the size of the project.\n> > 2. no need to declare anything in the header file, which is time\n> > consuming and a headache for developers.\n>\n> Sure, this all sound interesting in principle, and I think the answer is\n> definitely \"we're not opposed in principle, but if you're interested\n> let's see patches\".\n>\n> But whether this is worthwhile is something that really can't be\n> answered until someone (i.e. you) puts in the legwork of implementing\n> it.\n>\n> You'll then run into various trade-offs you'd have to make, and issues\n> you may not have forseen. Just some I can think of offhand:\n>\n> * It's unclear if you mean that we'd commit the generated files or\n> not. If \"not\" then our Makefile will need to learn to do two-stage\n> compilation. I.e. we'd ship a copy of the makeheader tool, build\n> that, build the headers, and then do our \"real\" build.\n>\n> I happen to have an implementation of that \"two-stage\" compilation\n> for entirely different reasons (being able to do configure/probes for\n> our compilation), but *just* doing that is non-trivial.\n>\n> * The way we document various APIs now is via manually curated header\n> files, e.g. how would a strbuf.h look like in this model you're\n> proposing?\n>\n> Obviously we could move those comments to the *.c file, but right now\n> we have a convention of implementation comments going in the *.c\n> file, but the API docs going in the *.h.\n>\n> We could tell them apart with \"/*\" v.s. \"/**\" comments, as we do\n> now. But part of the point of having them in the *.h file is that you\n> can easily skim the docs & APi definition. Putting the docs in the\n> much bigger *.c file wouldn't be nice.\n>\n> * We'd have another not-quite-compiler C-parser running on git.git,\n> right now we basically have a dependency on spatch's parsing. See\n> 5cf88fd8b05 (git-compat-util.h: use \"UNUSED\", not \"UNUSED(var)\",\n> 2022-08-25).\n>\n> Is this parser smart enough to handle all the edge cases? E.g. for\n> KHASH_INIT() we define interfaces via a macro-indirection, so an\n> auto-generated *.h needs to resolve the macros in the *.c file.\n"},{"id":"463359","messageId":"YyrHKmNIoV70sATE@danh.dev","threadId":"58454","inReplyTo":"CA+J78MUM=JiAF7R_8oV23OQ-LndJbRm4AUdPsgS4HT4SduFgiw@mail.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2022-09-21T08:11:22Z","receivedAt":"2022-09-21T08:11:30Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2022-09-21 13:23:11+0530, Skrab Sah wrote:\n> 1. We would not commit the generated file.\n> 2. There are different ways we can install the makeheaders tool.\n> 3. Makefile will first generate the header file then other compilation.\n\nWithout seeing the patches, here is my guess, you will make us only\nwrite source code in '*.c' and extract declaration from foo.c to foo.h\nAnd that will save us some time to write (and update) declaration in foo.h\n\nHowever, whenever foo.c is updated, foo.h will need to be\nre-generated, thus all other users of foo.h will need to re-compiled.\nThus, increase compilation time. We can work-around by write the\noutput to foo.h+ and compare to foo.h, discard it if its content\nhasn't been changed. It still takes time to analyse foo.c and write to\nfoo.h+\n\nIn addition, I'm not sure where would you put the struct, enum,\npreprocessor declaration, and compat stuff.\n\nIf my understanding is correct, it's not worth the effort, IMHO.\n\n-- \nDanh\n"},{"id":"463360","messageId":"CA+J78MXtkYOALDqY4Bxva6nm+vJNtN_hO4w4vFTzx-7izP=zBA@mail.gmail.com","threadId":"58454","inReplyTo":"YyrHKmNIoV70sATE@danh.dev","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Skrab Sah","fromEmail":"skrab.sah@gmail.com","sentAt":"2022-09-21T08:46:09Z","receivedAt":"2022-09-21T08:46:59Z","isPatch":false,"sender":{"key":"skrab.sah@gmail.com","avatar":null},"body":"For foo.h and foo.h+, makeheaders tool already has a feature in it.\nfor more info. read the manual.\n\nThe tool is fast enough to handle the situation of generating a single file.\nnote: we can also manually edit header file, it is not gone only it's\nauto generated.\n\nFor situations like struct, enum, preprocessor declaration, and compat\nstuff I have mentioned in the previous mail.\n\nOn Wed, 21 Sept 2022 at 13:41, Đoàn Trần Công Danh wrote:\n>\n> On 2022-09-21 13:23:11+0530, Skrab Sah wrote:\n> > 1. We would not commit the generated file.\n> > 2. There are different ways we can install the makeheaders tool.\n> > 3. Makefile will first generate the header file then other compilation.\n>\n> Without seeing the patches, here is my guess, you will make us only\n> write source code in '*.c' and extract declaration from foo.c to foo.h\n> And that will save us some time to write (and update) declaration in foo.h\n>\n> However, whenever foo.c is updated, foo.h will need to be\n> re-generated, thus all other users of foo.h will need to re-compiled.\n> Thus, increase compilation time. We can work-around by write the\n> output to foo.h+ and compare to foo.h, discard it if its content\n> hasn't been changed. It still takes time to analyse foo.c and write to\n> foo.h+\n>\n> In addition, I'm not sure where would you put the struct, enum,\n> preprocessor declaration, and compat stuff.\n>\n> If my understanding is correct, it's not worth the effort, IMHO.\n>\n> --\n> Danh\n"},{"id":"463373","messageId":"xmqqpmfo66b2.fsf@gitster.g","threadId":"58454","inReplyTo":"CA+J78MWvOEbJY6+NcLFn0SJGMZn=N7QUMwc=Bta+uHicvD892w@mail.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-09-21T16:28:01Z","receivedAt":"2022-09-21T16:41:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Skrab Sah writes:\n\n> Let me elaborate to you, how and why I wanted to implement the\n\nNo, I won't let you ;-), and that was the most important part you\nseem to have missed in the message you are responding to: we do not\nwork with the handwaving.\n\n> 2. no need to declare anything in the header file, which is\n> time consuming and a headache for developers.\n\nThis alone is enough to convince me that this should not be done.\n\nUnless the tool can infer the intent while generating the headers\nand place comments describing why it exists and what it and its\nparameters mean next to the function definition it produces, that\nis, in which case I may be OK. As developers become more and more\nexperienced, they will invest more and more time in getting the\ninterface right. We shouldn't target developers who find the time\nto do so a waste and headache.\n\nThanks.\n"},{"id":"463500","messageId":"220923.861qs25yr8.gmgdl@evledraar.gmail.com","threadId":"58454","inReplyTo":"CA+J78MUM=JiAF7R_8oV23OQ-LndJbRm4AUdPsgS4HT4SduFgiw@mail.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-09-23T07:28:03Z","receivedAt":"2022-09-23T07:35:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Sep 21 2022, Skrab Sah wrote:\n\n> [...]\n> Is Makefile generated by another script?\n> [...]\n> For patches, I need some time and your help.\n\nAside from what Junio noted in another reply: I and others here are\ngenerally happy to help, but when you're proposing to entirely re-do how\na part of our build process works, then you really should know the\nanswers to not only the basics (\"is the Makefile generated?\"), but also\nthe more complex interactions.\n\nIf you're still interested I think there's good things to work on in\nthis area, but starting smaller (e.g. my upthread iwyu suggestion, or\nsimilar) would be much better.\n\nI.e. think about the practical benefits of a proposed big rewrite are,\nand whether there's ways to get some large portion of that in easier\nways.\n\n> On Tue, 20 Sept 2022 at 15:43, Ævar Arnfjörð Bjarmason wrote:\n>>\n>>\n>> On Tue, Sep 20 2022, Skrab Sah wrote:\n>>\n>> > Let me elaborate to you, how and why I wanted to implement the\n>> > makeheaders tool in the project.\n>> >\n>> > First of all, this program will automatically generate c header(.h)\n>> > files for specified c source(.c) files, which will help the developer.\n>> >\n>> > Here the test shows how the tool can be implemented in different\n>> > cases: https://github.com/skrab-sah/makeheaders-test\n>> >\n>> >\n>> > pros:\n>> > 1. it will slightly reduce the size of the project.\n>> > 2. no need to declare anything in the header file, which is time\n>> > consuming and a headache for developers.\n>>\n>> Sure, this all sound interesting in principle, and I think the answer is\n>> definitely \"we're not opposed in principle, but if you're interested\n>> let's see patches\".\n>>\n>> But whether this is worthwhile is something that really can't be\n>> answered until someone (i.e. you) puts in the legwork of implementing\n>> it.\n>>\n>> You'll then run into various trade-offs you'd have to make, and issues\n>> you may not have forseen. Just some I can think of offhand:\n>>\n>> * It's unclear if you mean that we'd commit the generated files or\n>> not. If \"not\" then our Makefile will need to learn to do two-stage\n>> compilation. I.e. we'd ship a copy of the makeheader tool, build\n>> that, build the headers, and then do our \"real\" build.\n>>\n>> I happen to have an implementation of that \"two-stage\" compilation\n>> for entirely different reasons (being able to do configure/probes for\n>> our compilation), but *just* doing that is non-trivial.\n>>\n>> * The way we document various APIs now is via manually curated header\n>> files, e.g. how would a strbuf.h look like in this model you're\n>> proposing?\n>>\n>> Obviously we could move those comments to the *.c file, but right now\n>> we have a convention of implementation comments going in the *.c\n>> file, but the API docs going in the *.h.\n>>\n>> We could tell them apart with \"/*\" v.s. \"/**\" comments, as we do\n>> now. But part of the point of having them in the *.h file is that you\n>> can easily skim the docs & APi definition. Putting the docs in the\n>> much bigger *.c file wouldn't be nice.\n>>\n>> * We'd have another not-quite-compiler C-parser running on git.git,\n>> right now we basically have a dependency on spatch's parsing. See\n>> 5cf88fd8b05 (git-compat-util.h: use \"UNUSED\", not \"UNUSED(var)\",\n>> 2022-08-25).\n>>\n>> Is this parser smart enough to handle all the edge cases? E.g. for\n>> KHASH_INIT() we define interfaces via a macro-indirection, so an\n>> auto-generated *.h needs to resolve the macros in the *.c file.\n\n"},{"id":"463565","messageId":"CA+J78MV2tanEUNBOdWdQ6xmXBoDnKzerox6GAvzDU+V5V0MHFA@mail.gmail.com","threadId":"58454","inReplyTo":"220923.861qs25yr8.gmgdl@evledraar.gmail.com","subject":"Re: what if i use makeheader tool to generate c header file, it would be accepted.","fromName":"Skrab Sah","fromEmail":"skrab.sah@gmail.com","sentAt":"2022-09-24T08:19:47Z","receivedAt":"2022-09-24T08:21:40Z","isPatch":false,"sender":{"key":"skrab.sah@gmail.com","avatar":null},"body":"https://github.com/git/git/pull/1344\n\nhelp me in solving this.\nmy spec, debian x86_64.\n\nOn Fri, 23 Sept 2022 at 13:05, Ævar Arnfjörð Bjarmason wrote:\n>\n>\n> On Wed, Sep 21 2022, Skrab Sah wrote:\n>\n> > [...]\n> > Is Makefile generated by another script?\n> > [...]\n> > For patches, I need some time and your help.\n>\n> Aside from what Junio noted in another reply: I and others here are\n> generally happy to help, but when you're proposing to entirely re-do how\n> a part of our build process works, then you really should know the\n> answers to not only the basics (\"is the Makefile generated?\"), but also\n> the more complex interactions.\n>\n> If you're still interested I think there's good things to work on in\n> this area, but starting smaller (e.g. my upthread iwyu suggestion, or\n> similar) would be much better.\n>\n> I.e. think about the practical benefits of a proposed big rewrite are,\n> and whether there's ways to get some large portion of that in easier\n> ways.\n>\n> > On Tue, 20 Sept 2022 at 15:43, Ævar Arnfjörð Bjarmason wrote:\n> >>\n> >>\n> >> On Tue, Sep 20 2022, Skrab Sah wrote:\n> >>\n> >> > Let me elaborate to you, how and why I wanted to implement the\n> >> > makeheaders tool in the project.\n> >> >\n> >> > First of all, this program will automatically generate c header(.h)\n> >> > files for specified c source(.c) files, which will help the developer.\n> >> >\n> >> > Here the test shows how the tool can be implemented in different\n> >> > cases: https://github.com/skrab-sah/makeheaders-test\n> >> >\n> >> >\n> >> > pros:\n> >> > 1. it will slightly reduce the size of the project.\n> >> > 2. no need to declare anything in the header file, which is time\n> >> > consuming and a headache for developers.\n> >>\n> >> Sure, this all sound interesting in principle, and I think the answer is\n> >> definitely \"we're not opposed in principle, but if you're interested\n> >> let's see patches\".\n> >>\n> >> But whether this is worthwhile is something that really can't be\n> >> answered until someone (i.e. you) puts in the legwork of implementing\n> >> it.\n> >>\n> >> You'll then run into various trade-offs you'd have to make, and issues\n> >> you may not have forseen. Just some I can think of offhand:\n> >>\n> >> * It's unclear if you mean that we'd commit the generated files or\n> >> not. If \"not\" then our Makefile will need to learn to do two-stage\n> >> compilation. I.e. we'd ship a copy of the makeheader tool, build\n> >> that, build the headers, and then do our \"real\" build.\n> >>\n> >> I happen to have an implementation of that \"two-stage\" compilation\n> >> for entirely different reasons (being able to do configure/probes for\n> >> our compilation), but *just* doing that is non-trivial.\n> >>\n> >> * The way we document various APIs now is via manually curated header\n> >> files, e.g. how would a strbuf.h look like in this model you're\n> >> proposing?\n> >>\n> >> Obviously we could move those comments to the *.c file, but right now\n> >> we have a convention of implementation comments going in the *.c\n> >> file, but the API docs going in the *.h.\n> >>\n> >> We could tell them apart with \"/*\" v.s. \"/**\" comments, as we do\n> >> now. But part of the point of having them in the *.h file is that you\n> >> can easily skim the docs & APi definition. Putting the docs in the\n> >> much bigger *.c file wouldn't be nice.\n> >>\n> >> * We'd have another not-quite-compiler C-parser running on git.git,\n> >> right now we basically have a dependency on spatch's parsing. See\n> >> 5cf88fd8b05 (git-compat-util.h: use \"UNUSED\", not \"UNUSED(var)\",\n> >> 2022-08-25).\n> >>\n> >> Is this parser smart enough to handle all the edge cases? E.g. for\n> >> KHASH_INIT() we define interfaces via a macro-indirection, so an\n> >> auto-generated *.h needs to resolve the macros in the *.c file.\n>\n"}]}