From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 11529-done@debbugs.gnu.org, Gnulib bugs <bug-gnulib@gnu.org>
Subject: bug#11529: redoing gnulib import to avoid 8+3 glitches
Date: Mon, 21 May 2012 12:05:17 -0700 [thread overview]
Message-ID: <4FBA91ED.8030605__32721.929861191$1337627191$gmane$org@cs.ucla.edu> (raw)
In-Reply-To: <83txz9xvsm.fsf@gnu.org>
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.
prev parent reply other threads:[~2012-05-21 19:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-21 3:12 bug#11529: redoing gnulib import to avoid 8+3 glitches Paul Eggert
2012-05-21 17:56 ` Eli Zaretskii
2012-05-21 19:05 ` Paul Eggert [this message]
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='4FBA91ED.8030605__32721.929861191$1337627191$gmane$org@cs.ucla.edu' \
--to=eggert@cs.ucla.edu \
--cc=11529-done@debbugs.gnu.org \
--cc=bug-gnulib@gnu.org \
--cc=eliz@gnu.org \
/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.