Iconv.html and iconv.html

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20221210/679d3272/attachment.sig>