emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Files from gnulib


From: Eli Zaretskii
Subject: Re: Files from gnulib
Date: Tue, 25 Jan 2011 23:54:47 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Paul Eggert <address@hidden>, address@hidden,
>         address@hidden, address@hidden
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]