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.4 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 E85221F506 for ; Wed, 21 Sep 2022 07:54:36 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="QWiFFVev"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231248AbiIUHxe (ORCPT ); Wed, 21 Sep 2022 03:53:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229687AbiIUHx3 (ORCPT ); Wed, 21 Sep 2022 03:53:29 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB52886724 for ; Wed, 21 Sep 2022 00:53:23 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id j12so5095949pfi.11 for ; Wed, 21 Sep 2022 00:53:23 -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=FpfrbPTPRH80ikFsvwFTF0DbdWn8s4wMnpB694bjstA=; b=QWiFFVev/yXENDY4+VuDsbH1GT+U4uGEUDTcn4fS3mWYyzCze+1pltJuVkODl9V9Nm rPV4ujcGJmGIaMjtOiYvCxgB6YCEn79uVmkHqkqbcOuBcLZE/BYVAou0CoGtgbCJZCGH BP0BFd8DJ2TsnE+xVnnQaQSkf5QB2PxfoCxEAWmxN9oGaUl4EPWD+kLxGza/zANCZJTK /yjKM8WRtdRVkqa13Y+/TiEdrxy3Fv2vdfqX30OugUIkij4dsS8ZMEeHCyfcw9tJ7WOV mw6DYZRLOPjduTeY5H5Qw0H5gQPvsLPMDmyBGBEndvjH2nd73yHffqWrjMnHChqA+NYX nkwg== 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=FpfrbPTPRH80ikFsvwFTF0DbdWn8s4wMnpB694bjstA=; b=ATVUIsJ8y2UQnbXd+OzIpyQkOBODXTwubmkIMHGoIhqLF4k1B8obeZK0pGgmLoY1ok AgwkDaQxZFPCXqWrOgWzz3UPlunKUPizMgGfbkrbiA8Uw37WPrCp5I9UfQx1LMCy8xdt BVIVynJAwjfRxpG90rzjAesfCnwL9Tojpw8i9FTWmqlEOuHFfGJH9+vsI82b3mxZZXh4 5Ff02tNW85z1+hjYBJ2BalH7VjFyHa5y3rkH7pWgIPc02//teBe+hw6cd1p4SeZQpJWE T03diy6bb/7VEl5Yhw4wQED70z6OWCrApcY1AXohVmjN+F75/5EtUl+JH+n4GKYxwo6/ +E8w== X-Gm-Message-State: ACrzQf36bhuhCQiD1CqW3KhWYOtTTvNwz9vxWSDL+aZSZuvg6O1LhypU Mn0qq6Q+fNuuV2TsRhndBY1VBpG9jylF50EE4O0= X-Google-Smtp-Source: AMsMyM7EVBOP4HDx5acMY0NwHbtZniqV5jasjgGgMunftIfG9Eib9n4ByY6nrF9nkFFts4vx18dvQTyTG89oz2SkLxM= X-Received: by 2002:a63:982:0:b0:43b:e67b:988c with SMTP id 124-20020a630982000000b0043be67b988cmr2132466pgj.35.1663746802856; Wed, 21 Sep 2022 00:53:22 -0700 (PDT) MIME-Version: 1.0 References: <220919.86zgev635z.gmgdl@evledraar.gmail.com> <220920.86illi5p6w.gmgdl@evledraar.gmail.com> In-Reply-To: <220920.86illi5p6w.gmgdl@evledraar.gmail.com> From: Skrab Sah Date: Wed, 21 Sep 2022 13:23:11 +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 1. We would not commit the generated file. 2. There are different ways we can install the makeheaders tool. 3. Makefile will first generate the header file then other compilation. 4. For API docs, there is one multi-line comment in the header file that we can put in at the top of the .c file and also it will automatically be copied in the .h file if we want. 5. makeheaders tools is fast and small and it will not run always, only when its respective file is changed. 6. As I showed you before, we have different approaches to handle different things so, it will be better to see in the patches. I think the patches will show you a better figure. for patches, in makefile we need to add some script for the makeheaders too= l. And the Makefile is too big and complicated to handle, it will consume time= . Is Makefile generated by another script? For patches, I need some time and your help. On Tue, 20 Sept 2022 at 15:43, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason 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.