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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11529 in the body.
You can then email your comments to 11529 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 #10 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: redoing gnulib import to avoid 8+3 glitches
Date: Mon, 21 May 2012 20:56:25 +0300

> Date: Sun, 20 May 2012 20:12:53 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>
> 
> --- 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

Thanks, but I'd rather we don't go that way.  We've been through this
before: this cure is worse than the disease, certainly for me.  The
one package where I actually tried that (GDB) proved to me that this
way lies madness.

Is this the best that can be done?  Could the offending file be
renamed in gnulib in some way that eliminates the problem?

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.

Message #15 received at 11529-done <at> debbugs.gnu.org (full text, mbox):

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.

Previous Next

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