From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23C57C4332F for ; Mon, 17 Oct 2022 07:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229817AbiJQH4H (ORCPT ); Mon, 17 Oct 2022 03:56:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230046AbiJQH4D (ORCPT ); Mon, 17 Oct 2022 03:56:03 -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 220565B53A for ; Mon, 17 Oct 2022 00:56:00 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id d26so22964225eje.10 for ; Mon, 17 Oct 2022 00:56: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 :message-id:reply-to; bh=wIVsKOsohEeLt1l7sD7U/BbaHSNYR01ZU7Bfgptp8Ww=; b=G+xcEFf2h0x3g4DdyCyrWL2pxFw/McJVp7zUDuHsDNIwXXW4Ozwjj+ZzvoNj09fDHS DE0q2dQmP5bPmSAJ1AwdtkPUu641qMnXz2ZHDpIJH5QQkWpue7p+7jOPAydlxcKY7N9Z Lv7r1heciic/UmehU5CHMsON/DsEQyYGqUXEsYgrlJqecamIzhUefrgnw8cBFB5OXL9Q ML4RWM/RkoQoXQ8dGBa+AeV3FtxwFvf6q1XHmluGxMT/pFISTfwRhIJb/SPoftKESoWa hK7nBPjiV09jV9bTLQEV7nhDkr6+6rez4DUAC84MIz6xNutKtBm7tVi6F+FUcg/Ookow M82A== 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:message-id:reply-to; bh=wIVsKOsohEeLt1l7sD7U/BbaHSNYR01ZU7Bfgptp8Ww=; b=2wzlSFupXupIcoQ1BSe9HDWzAw/M18p4dP3Oh2E/wzqd3SLdx/ZrNl3xc5Io+tqYJ2 7PxdoBQIEIywz7H0HnKBVKHB1O+GtDXcMlOPFQi7mO0ZxdL1MtTj57zHHXXNUWl9a8RN P4mTZgUrowokMVzxe3QJlbYXp1407WN2ReN23ViDMAGNisrgaURf2kKV+VKFhVNp3Z9z edRaNb4LEI0LxCZQwLfV+DU2htGuXDS7Ohh2v8D8700h00I/LTT5gtU9qddCKilc728p ph2+T4/gASbVYZcDNAsEBXDiq43DR7Eh2nCK6E18ySQC9M+KnsMLgBkZMRKtITjJOnQJ WByw== X-Gm-Message-State: ACrzQf3zBQibQTavXGdHfXSHLxvLb0xaQWd7er6j1vM1ar/LaKz6zmFo +VJr2xZHweDry4Y5fA7H+vHpaL7m0zqg+iKh4fo= X-Google-Smtp-Source: AMsMyM6oLwLL54GvbH3+wMSDkiM/uE+hriHE/7F3ey03sBHJtQL9mI1Y+pzPGa7NNTLws4HLVLJGFQ7OHkpCNzzWrF0= X-Received: by 2002:a17:907:2723:b0:78e:22f9:f16a with SMTP id d3-20020a170907272300b0078e22f9f16amr7369372ejl.682.1665993359018; Mon, 17 Oct 2022 00:55:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Skrab Sah Date: Mon, 17 Oct 2022 13:25:46 +0530 Message-ID: Subject: Re: [PATCH v2] abspath.h file is generated by makeheaders tool To: =?UTF-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZyBEYW5o?= Cc: Junio C Hamano , skrab-sah via GitGitGadget , git@vger.kernel.org, =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org > I find it a bit irresponsible to leave the suggestion sounding as if > this is a good idea as long as it does not break cross-compilation, > which will (mis)lead the original poster to waste even more time on > this topic (and waste others' time on responding to it). No. no. it's not for the previous replay i am asking for. Back in the days, I was asked by =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason. " * 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." My answer was. "There are different ways we can install the makeheaders tool." As the related question asked, I remembered it. so, I asked as this will solve the cross-compilation problem also, if it is good. > so let me repeat what I already said a few times. > > Whether the headers mechanically generated gets committed or not, > this line of change is unwelcome. Developers should be able to look > at the header files (and interface document, if we ever generate one > out of structured comments in the header files) when using common > functions that they are not (yet) familiar with, and we want to see > our header files manually curated. You repeated the question for me so, really sorry. I know you have already told me that, and it is important also as generally people try to find documentation for function in the header file. It is also not good when sharing libraries and its related header files without documentation. I tried to find the solution. By reading the manual and By viewing the source code, I found it doesn't support it. So, I am going to either modify it or create a new one. And also I have remembered all your points, I will try to implement it. > I'm sorry. > > I thought my earlier voice to not support this proposal was't > necessary to be re-iterated. I only think that if this proposal > somehow got accepted (despite I don't like this proposal), something > needs to be fixed. > > I will be explicit next time. No. no. you don't need to be sorry. I know this proposal is not going to be accepted now. Too many things have to be done here and I am working on it. My question was. 1. Until now, are there any problems which need to be solved. 2. Why it gives errors in CI / win test (8) (pull_request) test. (Important= )