On 01/25/11 11:02, Eli Zaretskii wrote: > To read the instructions, you need to unpack the archive first.
That may have been true years ago, when the tarballs themselves were the main way that one could find out how to do maintenance. But that long ago stopped being true for Emacs. If I wanted to come up to speed on how to build Emacs for MS-DOS, the first thing I'd do would be a Google search, which would point me at places like <http://www.emacswiki.org/emacs-fr/EmacsForDOS> and <http://www.gnu.org/software/emacs/manual/html_node/emacs/MS_002dDOS.html>. If these places contain extraction instructions, that's good enough. >> djtar -n emacs-25.chg emacs-25.tgz > We use something like that in GDB, and the result is extremely > fragile and error-prone, Even if -n is currently error-prone in GDB, that does not mean that the approach is inherently error-prone, or that it must be error-prone in Emacs. For example, it should be pretty easy to check emacs-25.chg automatically; is that done with GDB? If not, and if checking is done by hand, I can understand why it might be error-prone; but an automated check should substantially reduce the number of errors. > If the decision is not to rename these few files in the Emacs > distribution, and instead ask me to cope with these complications, I > will understand that the knee-jerk reaction of too many members of > this community when they hear "MS-DOS" is more important that any > voice of reason I hope that you don't include me in members whose knees are jerking. Personally I would just rename the files in gnulib and be done with it, as none of the name changes seem to be onerous. However, we don't seem to have consensus for that now; I seem to be the only gnulib developer who would go that route. Also, the problem of non-8+3 file names does not seem to be limited to gnulib-derived files. All in all it sounds like automating the renaming on the MS-DOS side would be a reasonable thing to do. This is a bit of work but doesn't seem that hard. And if we get the automation working well with Emacs we could then apply similar ideas to GDB as well, and make GDB development less error-prone on MS-DOS.
