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.
