> From: Stefan Monnier <monn...@iro.umontreal.ca>
> Cc: Paul Eggert <egg...@cs.ucla.edu>, c...@stupidchicken.com,
> bug-gnulib@gnu.org, emacs-de...@gnu.org
> Date: Tue, 25 Jan 2011 16:03:16 -0500
>
> - let's try and get this "djtar -n emacs-25.chg emacs-25.tgz" to work
> reliably, e.g. by auto-building the emacs-25.chg file as part of
> make-dist, so there's no way for that file to be "missing renames".
Based on the experience from GDB, here are the problems with this
approach:
. The remapping of file names cannot be fully automated. Once all
limits on file names are removed ("we don't want even the
slightest impediment", says Jim), sooner or later you get to the
point where the number of files to be renamed becomes large and a
human needs to define how files will be renamed, because you want
names that at least remotely resemble the original ones, but still
don't clash in the 8+3 namespace. (I hope no one is seriously
entertaining the idea of producing meaningless names like
foo~123.c or ABC123EF.c, from some hash or whatever).
. Once the remapping is maintained by humans, it becomes unreliable.
. The unpacking instructions are part of the tarball, and need to be
extracted separately before the "main" extraction begins. More
importantly, the remapping file needs to be extracted before that
as well. This makes the entire unpacking procedure extremely
complicated and thus error-prone, except if the person who does
that is the one who designed it and wrote the instructions in the
first place.
In addition, there will be a need to deal with something that the GDB
distribution doesn't. In GDB, the files that are renamed during
unpacking are only those that are not used for the DOS build. By
contrast, here we want to rename files that are used during the build.
So there will be a need to edit all the files that reference the
renamed ones, before the build can begin. This can be done with Sed,
but the DOS shell doesn't have any way of recursively descending
through a directory tree. So, if we want to make this editing as part
of config.bat, the subdirectories of the Emacs tree will have to be
hard-coded in config.bat, which is yet another source of errors, when
a subdirectory is added or removed. (The alternative, of using a port
of GNU Find, would mean addition of another tool that is not required
today for building Emacs.)
Perhaps it's possible to solve all this in a satisfactory manner, but
doing so would require a lot of work, much more than I am willing to
invest. (I still want to finish development of bidirectional editing,
remember?) Given the small (yes, small!) fraction of files that ever
need to be renamed, the significant effort needed for getting this
particular alternative right is not justified.
