From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id DA0263832BAC for ; Fri, 9 Dec 2022 16:29:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA0263832BAC Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id 8BB99340F84; Fri, 9 Dec 2022 16:29:31 +0000 (UTC) Date: Sat, 10 Dec 2022 01:29:29 +0900 From: Mike Frysinger To: Torbjorn SVENSSON Cc: Newlib Subject: Re: Iconv.html and iconv.html Message-ID: References: <419fd802-0895-3c9e-dd0d-be9963d7a83b@foss.st.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ygxAOLx92A7Gd71c" Content-Disposition: inline In-Reply-To: <419fd802-0895-3c9e-dd0d-be9963d7a83b@foss.st.com> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --ygxAOLx92A7Gd71c Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02 Dec 2022 17:06, Torbjorn SVENSSON wrote: > I have been building a toolchain for the arm-none-eabi target using a=20 > rather recent snapshot of newlib. While building the html documentation,= =20 > I noticed that there will be generated the two files named Iconv.html=20 > and iconv.html. > While this works fine for case sensitive file systems, it's obvious that= =20 > this will not have the desired outcome on a case-insensitive file=20 > system, such as on Windows system. >=20 > The Iconv.html file contains the chapter description and the iconv.html= =20 > file contains the description of the iconv-function. >=20 > Can someone, with the knowledge of how these filenames are generated,=20 > change one of them so that the filenames differ on a case insensitive=20 > file system? the naming is straightforward -- the @node attribute is turned directly into the filename. we use @node Iconv for the chapter and @node iconv for the C function APIs. so the fix is to change one of them. the sub-areas have a 1-to-1 mapping to the chapter (e.g. stdio/->Stdio, iconv/->Iconv, etc...). the generated APIs similarly map source file names to the chapter (e.g. iconv.c->iconv, strncmp.c->strncmp). but they can map any number of functions inside those source files, and we might rename them as makes sense in general for our organization. so i'm more inclined to change the generated API chapters, and do it across the board instead of a one-off for iconv.c. anyone want to bikeshed the naming convention ? gen_xxx ? src_xxx ? there doesn't seem to be a standard here in the GNU toolchain space that i can see. bfd/ has a conflict, but they just do a one-off rename with bfd.texi->bfdt.texi for the makedoc output. -mike --ygxAOLx92A7Gd71c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmOTYmkACgkQQWM7n+g3 9YGB0RAA43EcHJayeKoZ5mSgmFTFieJ6GWKyhfBi+uA+dfGWNRwRgQmovtAnBRJk mvZFcUui2W05ddjbCAZ7n3n2mrhXUJkgLikJYiX9F7dhVd3h9bzH9b8yvE93u1Ib 7WZMZO0TpyVLpu7ruxVrSucgpvdCJc42LQh2PQkY+mOGio+MhUGkruDTEV6tpG3B 2C1o7WdbrLd8ITvnspAyKc2ixxeEmYWFQxci7fRlmkbt6JoPgmcEbBw7GE0XZG5d Q/UDvkUHjxX+gtkPDlICyJWq58lnkJEdAZ9AAjQaEnvQ7XXEoWfQmXhmK5Zf9X3D r/m78MDK/BkEieekpzmVDO2vLTfPic/dCabEmUFMrj1OTrRz5RD+AMEo4VS/3sfk Qv6n6JwXN7TpO5ccpBlfqeoifm6s9bq2Tu5qg31HsRAe41+T8XsW2t27W/e3wvm2 K27sw9QVJ96IiXyWShZnjgXiBrkPYDjr+sA4pglVjzxVy27wydEqKNCI7+qzPZuc 5q8Z7JmckDQjfBrgfh9qolZUIsA/pFuX0yFs5RYk3ZZvK5tNy3VDeHAxjhipIYJ9 I08Ws9E7aqASji54YnQqs6SplCfKj8r0QoAgu5aO0TfDHJCvy4noOtGX9VmLaTC3 +0D89pO2mHK4r1AqzsBCNL0KZ7TenmE2+0NhcwLfqAiHkeRhaGI= =+2fL -----END PGP SIGNATURE----- --ygxAOLx92A7Gd71c--