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.7 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,RCVD_IN_DNSWL_HI, 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 D34F41F506 for ; Fri, 23 Sep 2022 07:35:49 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="aZjakkIv"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230025AbiIWHfp (ORCPT ); Fri, 23 Sep 2022 03:35:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbiIWHfo (ORCPT ); Fri, 23 Sep 2022 03:35:44 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D48C4128487 for ; Fri, 23 Sep 2022 00:35:42 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id dv25so25994452ejb.12 for ; Fri, 23 Sep 2022 00:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to :user-agent:references:date:subject:cc:to:from:from:to:cc:subject :date; bh=Rybn7PFyL53K0mO/8UvVxIWjK4KWGn0NRuskXcEmtLY=; b=aZjakkIvEjrDDtjlsjr/hVxQ6jmIweeMw+o5A1hGt7fa9Aj88QAMtuuyouBJnoCwQQ hcLmC0c/+UqOXj1eYM1uBwSI2/3mSaydvlg+CfLKoPrzqe71FalK1ttCWCauymSXts3v 52kHuMQAbGKOO1fYPAdTSvnq0hylee1iRxwCireZjAHYfQiX4JaiihBt+R95vbspD98O a8dxkpUTn9Kr/Yath7BQubdWX0lgrUY3EcXe4Ttz7OuJlpJHtYoTWp5y4cV7phFIF/vT /h9ksyT3F0HJ90Yu3Ft1vwJ290/3CXgx3sSq0Rk8U27LIijg8UwKex7wwag2dR0nVQSU qoDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to :user-agent:references:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date; bh=Rybn7PFyL53K0mO/8UvVxIWjK4KWGn0NRuskXcEmtLY=; b=aLLq2nAx0M+80WpIpdN0zBpYCDaHUMP9c26IrxgW+FoJ3Wd8Jf9QW0Gs1f4091hc9T BmTlSs5DJzix/j7/MMX7IUp04/QXVuInNEppV5/xbG4eYwiIACBgITUs8Q5/inlWlZ/5 fbiTfqCZtZoI8SyxGlyF9jyGBbZB1YVtsBEIe9T6XA0iMCDExOe6nTsX62pNrQNJjWOa O/vUkUmttYCYAWSHgQ3FpSjiiWBgA4VFJ5Ok/35nSsilUBI2U88zDbzENZ1rFWh5a2XD DQd0XpjvCrVxQ+MxpXwnT7GzWQgrWrfc2mE2RHP8b5DaiIXiuLXOqMyknZAP1unZxN03 XTUg== X-Gm-Message-State: ACrzQf3DR2PdRcx/FN4XQo/Gj7PysbwL0fpAiRdWiXko8k3ry6g7SrIV ILvHmv7ILCgyfQ5OTdTAq9Q= X-Google-Smtp-Source: AMsMyM4xbOj4rBsCOCbaPDxWrS1n1u7dJXQccYwMjfL1K5adHF5CITBZF6lyQLZhfM1MLIYqYftibw== X-Received: by 2002:a17:906:6a23:b0:782:e8:1b7d with SMTP id qw35-20020a1709066a2300b0078200e81b7dmr5901632ejc.127.1663918541184; Fri, 23 Sep 2022 00:35:41 -0700 (PDT) Received: from gmgdl (dhcp-077-248-183-071.chello.nl. [77.248.183.71]) by smtp.gmail.com with ESMTPSA id 6-20020a170906318600b0073dcdf9b0bcsm3768591ejy.17.2022.09.23.00.35.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Sep 2022 00:35:40 -0700 (PDT) Received: from avar by gmgdl with local (Exim 4.96) (envelope-from ) id 1obdDn-003EnQ-2S; Fri, 23 Sep 2022 09:35:39 +0200 From: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason To: Skrab Sah Cc: Junio C Hamano , git@vger.kernel.org Subject: Re: what if i use makeheader tool to generate c header file, it would be accepted. Date: Fri, 23 Sep 2022 09:28:03 +0200 References: <220919.86zgev635z.gmgdl@evledraar.gmail.com> <220920.86illi5p6w.gmgdl@evledraar.gmail.com> User-agent: Debian GNU/Linux bookworm/sid; Emacs 27.1; mu4e 1.7.12 In-reply-to: Message-ID: <220923.861qs25yr8.gmgdl@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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 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.