From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 53AA71F506 for ; Sat, 24 Sep 2022 08:22:54 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="UiOSg4Ey"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233790AbiIXIVg (ORCPT ); Sat, 24 Sep 2022 04:21:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233536AbiIXIVL (ORCPT ); Sat, 24 Sep 2022 04:21:11 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC9391004A for ; Sat, 24 Sep 2022 01:20:00 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id c24so2090617plo.3 for ; Sat, 24 Sep 2022 01:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=9Bc8shZUybw3f0TuqoKA465XdUfNOrAC4z91nA0FifM=; b=UiOSg4EyjeRLwb3uj55xZBM+N22Ud7Q1G2CUF7iHY6yNBD1mjSxc8rM6VDFwYShA3E N00l1RFjJ+0UZOlcsyUXY0Uon15GOkshJjtJaBQ9Y+g6AXOMAqZ7EkR/oAowzHEk3wtQ 9rCwz8eocoHU0WUcHZidD/6V5Rnvgsk6ahqof/pnhWwX38KmAhnIJ/7IT71V0LOTSbKD FAN0IhT3yZXzNmnLVBQt2oKkx+eKMNYVwcivzAQQhW7YpKbxQRDm1W02i+5rPf8KR6SG ClyU0gTINiCOtDWlWwVk7yk0Bv3Vx1x1iT+tBXVY3ncR0gkqpSTpurRcZGq0EI/dOW0a dAPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=9Bc8shZUybw3f0TuqoKA465XdUfNOrAC4z91nA0FifM=; b=fl1rbP2EeInlLfp8A/tBBRlVvhcAzATfEAI/pPhose4MRKp7JVKzWE24FE5CM2q96L Yp5OlqzcMk1YICOm9h8EanwKPV4xYJCn/QXDept/n3s3heMLinMHDwlH+YiVLFXFIQEJ wuuSkpQ7wHptNGT+UmX+m+EzJcMcr33v08u9cYXrKdjlP7jomYE36o5AZT7iM9dNmxIM vejQm13R4yIlLXsn6eVAkQbmtSPK4ykZj3j+jWRfLZ+pidXACjDATFo+sduVyjAbOn4Q lq12vfgJ4BIs0+wmEu/2wQqZDHACkVP9PBevsk9lDWjjwP1z6wZUNddN0YRMcTfG/wAT YR8A== X-Gm-Message-State: ACrzQf2IATzxEK5osO2I34ohI3DmMdZ52vs8bl6+kY3jOAoyJIX3Kdq/ YDjrRpZ7J3RRI8k9hlHTI/Q10Ui37UAqYwMbFTkkxOg9Ybk= X-Google-Smtp-Source: AMsMyM5Q5mycdXu/FzgFhOvsQqyRSH06m3KenwVhgOC09hQdINmHNkAIA9DBfrgNzRifZ4Ti30lqko1Jb6z/w3MDFqM= X-Received: by 2002:a17:902:ec86:b0:177:f35c:e118 with SMTP id x6-20020a170902ec8600b00177f35ce118mr12026388plg.138.1664007599407; Sat, 24 Sep 2022 01:19:59 -0700 (PDT) MIME-Version: 1.0 References: <220919.86zgev635z.gmgdl@evledraar.gmail.com> <220920.86illi5p6w.gmgdl@evledraar.gmail.com> <220923.861qs25yr8.gmgdl@evledraar.gmail.com> In-Reply-To: <220923.861qs25yr8.gmgdl@evledraar.gmail.com> From: Skrab Sah Date: Sat, 24 Sep 2022 13:49:47 +0530 Message-ID: Subject: Re: what if i use makeheader tool to generate c header file, it would be accepted. To: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= Cc: Junio C Hamano , git@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason 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, =C3=86var Arnfj=C3=B6r=C3=B0 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 develope= r. > >> > > >> > 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 f= or > >> 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 n= ow > >> 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 y= ou > >> 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. >