From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 435433858C50 for ; Sat, 7 Jan 2023 09:21:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 435433858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 307345s8008607; Sat, 7 Jan 2023 10:21:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : from : subject : to : cc : content-type : content-transfer-encoding; s=selector1; bh=WlxmiJCkkX646sJnrETjy62ZVkXpapTZNldR/rgdTVI=; b=ipVz5ZEFTjURMpGZH8sOLsDKl3ZWtkb8J9Iggrf8tVkWLXu0evMpBs4eUpU43ALQOags y6w76vrW0yLSb9Hxptry8cfsHjI5tST8RCW6/JIcd042wJnADlVt1CWJOSoj16YViLUB bkEPgvw5oxAvBPS5/ipmB8yLXNNerfgX4qUUMR0bFNNCF1vhjHQsi0etLXZ37K3NaoCy k4OCoPh8oyWeC4mu3WYIpYjILh6MlfHhrvQaIBPlC1v3FEE0w5p7GvtvKaQoze6R4lrJ TleeHBDc2Lc4ADKkb+WrmWE1wtKgbLIKjSCsT4BSlKJbFR87SFeuvQ6h8TwcAbdhdhoK 9A== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3my0gnh0km-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Jan 2023 10:21:51 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DE10910002A; Sat, 7 Jan 2023 10:21:50 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id BC2B1235F3B; Sat, 7 Jan 2023 10:21:50 +0100 (CET) Received: from [10.252.8.65] (10.252.8.65) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.13; Sat, 7 Jan 2023 10:21:50 +0100 Message-ID: Date: Sat, 7 Jan 2023 10:21:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US From: Torbjorn SVENSSON Subject: Generated GDB documentation have colliding files on a case insensitive files system To: =?UTF-8?Q?Torbj=c3=b6rn_SVENSSON_via_Gdb-patches?= CC: Eli Zaretskii Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.252.8.65] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-07_02,2023-01-06_01,2022-06-22_01 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, If the HTML documentation is put on a case insensitive files system (like those used in Windows), there are 2 files that collides: qMemTags.html and QMemTags.html. Both the files contains a simple redirect to their corresponding anchor in General-Query-Packets.html, and there appears to be no link to [qQ]MemTags.html in any of the other generated HTML files. I'm currently leaning towards that these redirect files are not really needed and that they should have been omitted. As it's correct to document both qMemTags and QMemTags, and that the two RSP commands are indeed different, I see the following potential solutions to the collision: * Leave it as is and live with the collision for users extracting an archive with the HTML documentation on a case insensitive files system. * Use the "--no-split" argument to makeinfo to generate a single big HTML file for all the documentation rather than one HTML file per @node. This solution might have other consequences that I'm not aware of as there are multiple texi files in the GDB source tree... * After invoking makeinfo, remove all the generated redirect pages (appears to be ~214 files). Is there any other solution that I have no thought of? What solution is preferred? I've also started a thread on the bug-texinfo list about adding a warning for this problem when running the makeinfo command. The thread can be found here: https://lists.gnu.org/archive/html/bug-texinfo/2023-01/msg00030.html Kind regards, Torbjörn