public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
Cc: Newlib <newlib@sourceware.org>
Subject: Re: Iconv.html and iconv.html
Date: Sat, 10 Dec 2022 01:29:29 +0900	[thread overview]
Message-ID: <Y5NiaddLSK8OqMOU@vapier> (raw)
In-Reply-To: <419fd802-0895-3c9e-dd0d-be9963d7a83b@foss.st.com>

[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]

On 02 Dec 2022 17:06, Torbjorn SVENSSON wrote:
> I have been building a toolchain for the arm-none-eabi target using a 
> rather recent snapshot of newlib. While building the html documentation, 
> I noticed that there will be generated the two files named Iconv.html 
> and iconv.html.
> While this works fine for case sensitive file systems, it's obvious that 
> this will not have the desired outcome on a case-insensitive file 
> system, such as on Windows system.
> 
> The Iconv.html file contains the chapter description and the iconv.html 
> file contains the description of the iconv-function.
> 
> Can someone, with the knowledge of how these filenames are generated, 
> change one of them so that the filenames differ on a case insensitive 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-12-09 16:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02 16:06 Torbjorn SVENSSON
2022-12-09 16:29 ` Mike Frysinger [this message]
2022-12-09 16:40   ` Torbjorn SVENSSON
2022-12-10  8:29   ` Mike Frysinger
2022-12-10  8:29 ` [PATCH] newlib: info: tweak iconv node to avoid collisions Mike Frysinger
2022-12-13  1:28   ` Jeff Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y5NiaddLSK8OqMOU@vapier \
    --to=vapier@gentoo.org \
    --cc=newlib@sourceware.org \
    --cc=torbjorn.svensson@foss.st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).