all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Eric Blake <eblake@redhat.com>
Cc: Paul Eggert <eggert@CS.UCLA.EDU>, bug-gnulib <bug-gnulib@gnu.org>,
	cyd@stupidchicken.com, emacs-devel@gnu.org,
	monnier@IRO.UMontreal.CA, Eli Zaretskii <eliz@gnu.org>,
	Bruno Haible <bruno@clisp.org>
Subject: Re: Proposed gnulib renames
Date: Wed, 26 Jan 2011 17:36:42 +0100	[thread overview]
Message-ID: <87tygvmxk5.fsf@meyering.net> (raw)
In-Reply-To: <4D404396.9040600@redhat.com> (Eric Blake's message of "Wed, 26 Jan 2011 08:53:58 -0700")

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.



  parent reply	other threads:[~2011-01-26 16:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-26 15:53 Proposed gnulib renames Eric Blake
2011-01-26 16:08 ` Eric Blake
2011-01-26 16:36 ` Jim Meyering [this message]
2011-01-26 18:51   ` Eli Zaretskii
2011-01-26 18:59     ` Jim Meyering
2011-01-26 19:15       ` Eli Zaretskii
2011-01-26 19:48         ` Jim Meyering
2011-01-27  0:39   ` Paul Eggert
2011-01-27  4:11     ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2011-01-23 12:15 Files from gnulib Eli Zaretskii
2011-01-23 19:29 ` Paul Eggert
2011-01-24  3:26   ` Stefan Monnier
2011-01-24  4:01     ` Eli Zaretskii
2011-01-24 23:26       ` Paul Eggert
2011-01-25  4:00         ` Eli Zaretskii
2011-01-25  8:48           ` Paul Eggert
2011-01-25 11:24             ` Eli Zaretskii
2011-01-25 18:07               ` Paul Eggert
2011-01-25 19:02                 ` Eli Zaretskii
2011-01-25 21:03                   ` Stefan Monnier
2011-01-25 21:54                     ` Eli Zaretskii
2011-01-25 22:15                       ` Stefan Monnier
2011-01-26  1:05                         ` Paul Eggert
2011-01-26  4:12                           ` Eli Zaretskii
2011-01-26  6:01                             ` Eli Zaretskii
2011-01-26 15:19                               ` Proposed gnulib renames [was: Files from gnulib] Eric Blake
2011-01-26 15:58                                 ` Proposed gnulib renames Eli Zaretskii
2011-01-26 17:33                                   ` Bruno Haible
2011-01-26 18:40                                     ` Eli Zaretskii
2011-01-26 19:01                                       ` Eric Blake
2011-01-26 19:01                                       ` Bruno Haible
2011-01-26 19:18                                         ` Eli Zaretskii
2011-01-27  7:37                                     ` Paul Eggert
2011-01-27  9:57                                       ` Eli Zaretskii
2011-01-27  9:58                                       ` Eli Zaretskii
2011-01-27  9:59                                       ` Bruno Haible
2011-01-28  1:57                                         ` Paul Eggert
2011-01-27 10:14                                       ` Bruno Haible
2011-01-27 10:23                                         ` Bruno Haible
2011-01-28  0:32                                           ` Paul Eggert

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=87tygvmxk5.fsf@meyering.net \
    --to=jim@meyering.net \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=eblake@redhat.com \
    --cc=eggert@CS.UCLA.EDU \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.