bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed gnulib renames


From: Jim Meyering
Subject: Re: Proposed gnulib renames
Date: Wed, 26 Jan 2011 17:36:42 +0100

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]