From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, jifl@ecoscentric.com
Subject: Re: Fix doc index name on Windows
Date: Fri, 26 Nov 2010 12:52:00 -0000 [thread overview]
Message-ID: <83d3ps6y9b.fsf@gnu.org> (raw)
In-Reply-To: <201011261203.05391.pedro@codesourcery.com>
> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 26 Nov 2010 12:03:05 +0000
> Cc: Jonathan Larmour <jifl@ecoscentric.com>
>
> On Friday 26 November 2010 11:57:47, Eli Zaretskii wrote:
> > Then it's a bug in the cross-build version of makeinfo. There's code
> > in makeinfo/node.c:cm_node to handle the case when a file name
> > produced from a node name clashes with a name of an existing file
> > (produced from some other node name), due to limitations of the
> > underlying filesystem. What makeinfo does in that case is put all the
> > nodes whose names map to the same file name on that single file. I
> > see this behavior in action in the Windows port of makeinfo 4.8, and
> > the code which does this was written long before Texinfo 4.7 was
> > released, so you must have it as well.
>
> If such code is only triggerable on some hosts only, then IMO it
> is broken, because the resulting files will not be movable between
> hosts (e.g., generate on Unix, unpack on Windows/NTFS/FAT/Samba, whatnot).
IMO, "broken" is an exaggeration. How many tools did you see that
care about having their files produced on Unix be compatible with
NTFS? How many maintainers of GNU packages do you know who would even
consider a possibility of inserting NTFS-related limitations into
their codebase?
Usually, such problems are at best fixed for the hosts that use the
affected filesystems. And the cross-build environments should take
care of these issues, because they _do_ (or should) care.
> Is there a way to force that behaviour with a makeinfo command line
> switch or something of the sort?
Not that I know of. No one has ever asked for that, AFAIK. But it
should be trivial to add such a switch, now that I pointed to the code
which does that.
next prev parent reply other threads:[~2010-11-26 12:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 17:40 Jonathan Larmour
2010-11-25 18:21 ` Eli Zaretskii
2010-11-25 18:47 ` Jonathan Larmour
2010-11-26 11:55 ` Eli Zaretskii
2010-11-26 12:03 ` Pedro Alves
2010-11-26 12:52 ` Eli Zaretskii [this message]
2010-11-26 13:05 ` Pedro Alves
2010-11-26 15:07 ` Jonathan Larmour
2010-11-26 16:15 ` Eli Zaretskii
2010-11-27 9:24 ` Andreas Schwab
2010-11-26 15:12 ` Jonathan Larmour
2010-11-26 16:08 ` Eli Zaretskii
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=83d3ps6y9b.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jifl@ecoscentric.com \
--cc=pedro@codesourcery.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