bug#11529: redoing gnulib import to avoid 8+3 glitches

[Paul Eggert <eggert@cs.ucla.edu>]

Re <http://bugs.gnu.org/11529>, Eli Zaretskii wrote:

> Could the offending file be renamed in gnulib in some way that
> eliminates the problem?

We asked about that earlier, and the consensus on the gnulib side
was that porting to 8+3 file name restrictions was outside gnulib's
scope.  The solution that we came up at the time was to have the Emacs
sync-from-gnulib (now merge-gnulib) procedure rename a file both
before and after gnulib-tool, temporarily, so that gnulib-tool sees
the long file name but Emacs otherwise sees the short one.
Unfortunately this has proved to be a problem in practice.

One way to satisfy your request would be to add a gnulib-tool option
such as --file-name-prefix=PREFIX (default "gnulib-") so that
gnulib-tool can generate differently-named files that will happen to
fit in 8+3 limits if Emacs uses --file-name-prefix="gl-".
Unfortunately gnulib-tool is a 6700-line shell script with a
reasonable amount of complexity re caching and inferring file name
options; I briefly looked into writing and debugging such a change but
it looked like it might be more trouble than it's worth.

There's a project to rewrite gnulib-tool from scratch, for performance
reasons.  Maybe adding such an option will be easier if and when
that's done.  I'll CC: this message to bug-gnulib to give that project
a heads-up about this need.

> If not, just leave the file at its original name, without any changes
> to MS-DOS specific files, and I will find my own solution that will
> not bother anyone but me.

OK, thanks, that's simple, and I've done that for now and am closing
bug 11529.  We can improve this if and when gnulib-tool gets that option.