--- Begin Message ---
Subject: |
redoing gnulib import to avoid 8+3 glitches |
Date: |
Sun, 20 May 2012 20:12:53 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
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 <address@hidden>
+ 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 <address@hidden>
+ 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 <address@hidden>
+
+ 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 <address@hidden>
* 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
--- End Message ---
--- Begin Message ---
Subject: |
Re: redoing gnulib import to avoid 8+3 glitches |
Date: |
Mon, 21 May 2012 12:05:17 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
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.
--- End Message ---