GNU bug report logs - #11529
redoing gnulib import to avoid 8+3 glitches

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Mon, 21 May 2012 03:14:02 UTC

Severity: normal

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#11529: closed (redoing gnulib import to avoid 8+3 glitches)
Date: Mon, 21 May 2012 19:07:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Mon, 21 May 2012 12:05:17 -0700
with message-id <4FBA91ED.8030605 <at> cs.ucla.edu>
and subject line Re: redoing gnulib import to avoid 8+3 glitches
has caused the debbugs.gnu.org bug report #11529,
regarding redoing gnulib import to avoid 8+3 glitches
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
11529: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11529
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: redoing gnulib import to avoid 8+3 glitches
Date: Sun, 20 May 2012 20:12:53 -0700
On 05/07/2012 11:28 PM, Paul Eggert wrote:
> I'll look at
> reworking the 8+3-related build-procedure code that cost me time
> on Friday, so that it's less likely to do so in the future.

Here's a proposed patch to do that.
I've tested it on GNU/Linux, though not on DOS.

=== modified file 'ChangeLog'
--- ChangeLog	2012-05-21 02:33:13 +0000
+++ ChangeLog	2012-05-21 03:00:32 +0000
@@ -1,5 +1,14 @@
 2012-05-21  Paul Eggert  <eggert <at> cs.ucla.edu>
 
+	Use full name for m4/gnulib-comp.m4, except on DOS.
+	Previously the file was named m4/gl-comp.m4 on all hosts,
+	even though the file's name in gnulib is m4/gnulib-comp.m4.
+	This had a problem when merging from gnulib, as the code temporarily
+	renamed it to the full name, causing problems when interrupted.
+	With this change, the file ordinarily has its full name, except
+	that on DOS it has the shorter name.
+	* m4/gnulib-comp.m4: Rename from m4/gl-comp.m4.
+
 	Make merging from gnulib a script, not a makefile action.
 	Putting it in a makefile has some problems with reflection, as
 	merging from gnulib updates 'configure', which can update the makefile.

=== modified file 'admin/ChangeLog'
--- admin/ChangeLog	2012-05-21 02:33:13 +0000
+++ admin/ChangeLog	2012-05-21 03:00:32 +0000
@@ -1,5 +1,8 @@
 2012-05-21  Paul Eggert  <eggert <at> cs.ucla.edu>
 
+	Use full name for m4/gnulib-comp.m4, except on DOS.
+	* merge-gnulib: Leave m4/gnulib-comp.m4's name alone.
+
 	Make merging from gnulib a script, not a makefile action.
 	* merge-gnulib: New script, with actions moved here from
 	../Makefile.in.

=== modified file 'admin/merge-gnulib'
--- admin/merge-gnulib	2012-05-21 02:33:13 +0000
+++ admin/merge-gnulib	2012-05-21 03:00:32 +0000
@@ -79,10 +79,8 @@
   exit 1
 }
 
-cp -- "$src"m4/gl-comp.m4 "$src"m4/gnulib-comp.m4 &&
 "$gnulib_srcdir"/gnulib-tool --dir="$src" $GNULIB_TOOL_FLAGS $GNULIB_MODULES &&
 rm -- "$src"m4/gnulib-cache.m4 "$src"m4/warn-on-use.m4 &&
-mv -- "$src"m4/gnulib-comp.m4 "$src"m4/gl-comp.m4 &&
 cp -- "$gnulib_srcdir"/build-aux/texinfo.tex "$src"doc/misc &&
 cp -- "$gnulib_srcdir"/build-aux/move-if-change "$src"build-aux &&
 autoreconf -i -I m4 -- ${src:+"$src"}

=== renamed file 'm4/gl-comp.m4' => 'm4/gnulib-comp.m4'
=== modified file 'msdos/ChangeLog'
--- msdos/ChangeLog	2012-05-19 18:04:49 +0000
+++ msdos/ChangeLog	2012-05-21 03:00:32 +0000
@@ -1,3 +1,10 @@
+2012-05-21  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Use full name for m4/gnulib-comp.m4, except on DOS.
+	* INSTALL: Describe how to rename m4/gnulib-comp.m4 to m4/gl-comp.m4
+	when unpacking.
+	* sedlibcf.inp: Substitute the shorter name for the longer.
+
 2012-05-19  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	* sed2v2.inp (HAVE_MBLEN): Remove.

=== modified file 'msdos/INSTALL'
--- msdos/INSTALL	2012-01-19 07:21:25 +0000
+++ msdos/INSTALL	2012-05-21 03:00:32 +0000
@@ -73,6 +73,10 @@
 67-character limit on the file-name length imposed by DOS filesystems.
 When prompted by `djtar' for a different name for these files, just
 press [Enter] to skip them: they are not needed for the DJGPP build.
+Similarly, unpacking complains that the file names m4/gnulib-comp.m4
+and m4/gnulib-common.m4 clash when truncated to DOS 8.3 limits; when
+prompted by 'djtar' for an alternate name for m4/gnulib-comp.m4,
+choose the name m4/gl-comp.m4.
 
 If you want to print international characters, install the intlfonts
 distribution.  For this, create a directory called `fonts' under the

=== modified file 'msdos/sedlibcf.inp'
--- msdos/sedlibcf.inp	2012-01-05 09:46:05 +0000
+++ msdos/sedlibcf.inp	2012-05-21 03:00:32 +0000
@@ -19,4 +19,5 @@
 #
 # ----------------------------------------------------------------------
 s/c++defs/cxxdefs/g
+s/gnulib-comp\.m4/gl-comp.m4/g
 s/\([a-zA-Z0-9_]*\)\.in\.h/\1.in-h/g


[Message part 3 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11529-done <at> debbugs.gnu.org, Gnulib bugs <bug-gnulib <at> gnu.org>
Subject: Re: redoing gnulib import to avoid 8+3 glitches
Date: Mon, 21 May 2012 12:05:17 -0700
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.



This bug report was last modified 13 years and 86 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.