From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: Proposed gnulib renames Date: Wed, 26 Jan 2011 17:36:42 +0100 Message-ID: <87tygvmxk5.fsf@meyering.net> References: <4D404396.9040600@redhat.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1296059829 29767 80.91.229.12 (26 Jan 2011 16:37:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 26 Jan 2011 16:37:09 +0000 (UTC) Cc: Paul Eggert , bug-gnulib , cyd@stupidchicken.com, emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, Eli Zaretskii , Bruno Haible To: Eric Blake Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Jan 26 17:37:03 2011 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pi8Mh-0002fr-4b for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 17:37:03 +0100 Original-Received: from localhost ([127.0.0.1]:56014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi8Mg-00083c-47 for gnu-bug-gnulib@m.gmane.org; Wed, 26 Jan 2011 11:37:02 -0500 Original-Received: from [140.186.70.92] (port=56591 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pi8MR-000829-2P for bug-gnulib@gnu.org; Wed, 26 Jan 2011 11:36:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pi8MP-0005M6-MP for bug-gnulib@gnu.org; Wed, 26 Jan 2011 11:36:46 -0500 Original-Received: from mx.meyering.net ([82.230.74.64]:34203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pi8MP-0005LN-9k; Wed, 26 Jan 2011 11:36:45 -0500 Original-Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id CCD0F600A5; Wed, 26 Jan 2011 17:36:42 +0100 (CET) In-Reply-To: <4D404396.9040600@redhat.com> (Eric Blake's message of "Wed, 26 Jan 2011 08:53:58 -0700") Original-Lines: 148 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:24993 gmane.emacs.devel:135034 Archived-At: Eric Blake wrote: > [intentionally breaking threading and retitling this, to try and make it > easier to see replies to just this aspect of the thread] > > [well, my first attempt at breaking threading failed; apologies for the > duplicate, but here's a resend with identical contents to make good on > the promise of a new thread] > > On 01/25/2011 11:01 PM, Eli Zaretskii wrote: >> > Here's a compromise that at least I can live with; hope others can, >> > too: >> > >> > 1) For c++defs.h and the lib/*.in.h files: rely on the automatic >> > renaming by djtar. Files that reference those will be edited by >> > config.bat as part of configuring Emacs for the MS-DOS build. > > Paul already suggested renaming c++defs.h to cxxdefs.h in gnulib, which > makes sense to me in light of POSIX restrictions on portable filenames; > however, this module belongs to Bruno, so it is his call. > > As for the *.in.h files, the ONLY other files that refer to those at > build time are the Makefile snippets in module files that convert them > over to *.h replacement headers. Here's a link to some of the > back-discussion where we first settled on the name *.in.h in the first > place in Oct 2007 (we were previously using *_.h, but underscores are > painful to type in daily use; and also on the table at the time was the > rejected idea of *.h.in and *.hin): Hi Eric, While names containing two '.'s constitute part of the problem, (I have no fundamental objection to renaming those, btw) there's a more insidious one. Here are some of the reasons to try hard to avoid 8.3 constraints altogether. The following are some of the tuples of names in gnulib that collide in 8.3-land: basename-lgpl.c lib/basename-lgpl.c basename.c lib/basename.c c-strcasecmp.c lib/c-strcasecmp.c c-strcasestr.c lib/c-strcasestr.c c-strncasecmp.c lib/c-strncasecmp.c c-strcaseeq.h lib/c-strcaseeq.h c-strcasestr.h lib/c-strcasestr.h canonicalize-lgpl.c lib/canonicalize-lgpl.c canonicalize.c lib/canonicalize.c ctype_alnum.c lib/unictype/ctype_alnum.c ctype_alpha.c lib/unictype/ctype_alpha.c ctype_alnum.h lib/unictype/ctype_alnum.h ctype_alpha.h lib/unictype/ctype_alpha.h dup-safer-flag.c lib/dup-safer-flag.c dup-safer.c lib/dup-safer.c filenamecat-lgpl.c lib/filenamecat-lgpl.c filenamecat.c lib/filenamecat.c fd-safer-flag.c lib/fd-safer-flag.c fd-safer.c lib/fd-safer.c decompose-internal.c lib/uninorm/decompose-internal.c decomposing-form.c lib/uninorm/decomposing-form.c decomposition-table.c lib/uninorm/decomposition-table.c decomposition.c lib/uninorm/decomposition.c mbmemcasecmp.c lib/mbmemcasecmp.c mbmemcasecoll.c lib/mbmemcasecoll.c pipe-filter-gi.c lib/pipe-filter-gi.c pipe-filter-ii.c lib/pipe-filter-ii.c pr_bidi_arabic_digit.c lib/unictype/pr_bidi_arabic_digit.c pr_bidi_arabic_right_to_left.c lib/unictype/pr_bidi_arabic_right_to_left.c pr_bidi_block_separator.c lib/unictype/pr_bidi_block_separator.c pr_bidi_boundary_neutral.c lib/unictype/pr_bidi_boundary_neutral.c pr_bidi_common_separator.c lib/unictype/pr_bidi_common_separator.c pr_bidi_control.c lib/unictype/pr_bidi_control.c pr_bidi_embedding_or_override.c lib/unictype/pr_bidi_embedding_or_override.c pr_bidi_eur_num_separator.c lib/unictype/pr_bidi_eur_num_separator.c pr_bidi_eur_num_terminator.c lib/unictype/pr_bidi_eur_num_terminator.c pr_bidi_european_digit.c lib/unictype/pr_bidi_european_digit.c pr_bidi_hebrew_right_to_left.c lib/unictype/pr_bidi_hebrew_right_to_left.c pr_bidi_left_to_right.c lib/unictype/pr_bidi_left_to_right.c pr_bidi_non_spacing_mark.c lib/unictype/pr_bidi_non_spacing_mark.c pr_bidi_other_neutral.c lib/unictype/pr_bidi_other_neutral.c pr_bidi_pdf.c lib/unictype/pr_bidi_pdf.c pr_bidi_segment_separator.c lib/unictype/pr_bidi_segment_separator.c pr_bidi_whitespace.c lib/unictype/pr_bidi_whitespace.c readlink.c lib/readlink.c readlinkat.c lib/readlinkat.c readtokens.c lib/readtokens.c readtokens0.c lib/readtokens0.c spawn_faction_addclose.c lib/spawn_faction_addclose.c spawn_faction_adddup2.c lib/spawn_faction_adddup2.c spawn_faction_addopen.c lib/spawn_faction_addopen.c spawn_faction_destroy.c lib/spawn_faction_destroy.c spawn_faction_init.c lib/spawn_faction_init.c spawnattr_destroy.c lib/spawnattr_destroy.c spawnattr_getdefault.c lib/spawnattr_getdefault.c spawnattr_getflags.c lib/spawnattr_getflags.c spawnattr_getpgroup.c lib/spawnattr_getpgroup.c spawnattr_getschedparam.c lib/spawnattr_getschedparam.c spawnattr_getschedpolicy.c lib/spawnattr_getschedpolicy.c spawnattr_getsigmask.c lib/spawnattr_getsigmask.c spawnattr_init.c lib/spawnattr_init.c spawnattr_setdefault.c lib/spawnattr_setdefault.c spawnattr_setflags.c lib/spawnattr_setflags.c spawnattr_setpgroup.c lib/spawnattr_setpgroup.c spawnattr_setschedparam.c lib/spawnattr_setschedparam.c spawnattr_setschedpolicy.c lib/spawnattr_setschedpolicy.c spawnattr_setsigmask.c lib/spawnattr_setsigmask.c strerror.c lib/strerror.c strerror_r.c lib/strerror_r.c striconv.c lib/striconv.c striconveh.c lib/striconveh.c striconveha.c lib/striconveha.c u16-casecmp.c lib/unicase/u16-casecmp.c u16-casecoll.c lib/unicase/u16-casecoll.c u16-casefold.c lib/unicase/u16-casefold.c u16-casemap.c lib/unicase/u16-casemap.c xstrtoul.c lib/xstrtoul.c xstrtoull.c lib/xstrtoull.c ... Perhaps no pair is used by emacs at the moment, but if we're going to accommodate by renaming every .in.h file, eventually we will have to address the other sort of problem, too. Renaming files like those to avoid the 8.3 collisions does not seem like the right move, especially since we (at least I) have no idea of the size of the user base we would be accommodating. Are we even sure that it is necessary? I would feel better about this if Eli were gung-ho to use something like doslfn, had tried it, but had found that there were some fundamentally unfixable and show-stopping flaw in its design.