From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12253 invoked by alias); 26 Nov 2010 13:05:52 -0000 Received: (qmail 12242 invoked by uid 22791); 26 Nov 2010 13:05:51 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Nov 2010 13:05:46 +0000 Received: (qmail 29070 invoked from network); 26 Nov 2010 13:05:44 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Nov 2010 13:05:44 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: Fix doc index name on Windows Date: Fri, 26 Nov 2010 13:05:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.33-29-realtime; KDE/4.4.5; x86_64; ; ) Cc: jifl@ecoscentric.com References: <4CEE9F77.1070509@eCosCentric.com> <201011261203.05391.pedro@codesourcery.com> <83d3ps6y9b.fsf@gnu.org> In-Reply-To: <83d3ps6y9b.fsf@gnu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011261305.38296.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00454.txt.bz2 On Friday 26 November 2010 12:54:40, Eli Zaretskii wrote: > > 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. Maybe. The emphasis should have been on "triggerable". I don't think one should have to build makeinfo for the host -- the build machine's makeinfo should be useable in canadian crosses to build the host's documentation. Like the build machine's coreutils, findutils, etc. are. > 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? Many. I didn't mean that the "limitation" should be be added by default, but as an option. > > 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. Thanks. Note that FWIW, I'd be perfectly happy with a change to our manual to work around the issue. We carry a similar patch in our tree. -- Pedro Alves