On 01/25/11 13:54, Eli Zaretskii wrote: > This makes the entire unpacking procedure extremely > complicated and thus error-prone
I don't see why. With GDB it's two commands: djtar -x -p -o gdb-7.2/djunpack.bat gdb-7.2.tar.gz > djunpack.bat djunpack gdb-7.2.tar.gz Why would it be more complicated than that for Emacs? > . Once the remapping is maintained by humans, it becomes unreliable. No, not if it's checked. Surely the check can be automated reliably. > 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.) That should not be a problem. 'find' is already required to build Emacs; for example, Makefile.in uses it. It is easy to run 'find' as part of the process that makes a distribution, and to put its output into config.bat or the equivalent, so there is no need to run 'find' under MS-DOS. > Perhaps it's possible to solve all this in a satisfactory manner, but > doing so would require a lot of work, I don't think it'd take much work to do the above. I can write scripts to do the check and to do the find, since they can all be done on a standard GNU platform. What else is needed? On 01/25/11 14:06, Eli Zaretskii wrote: > And what about the emacs-25.chg file? Would you expect users to > google for it as well, and copy-paste it into their shell window? No, I would expect users to extract it from the tarball much as is already done with GDB and djunpack.bat. That's simple, and it would work. >> For example, it should be pretty easy to check emacs-25.chg >> automatically; is that done with GDB? > > Yes, it is done. But it doesn't catch all the errors. How is that checking done, and what errors doesn't it catch? I don't see the checking in the GDB 7.2 distribution. > We are talking about renaming files in the Emacs repo. Why would > gnulib developers have any say in that? Because we automatically sync files from gnulib into Emacs. What I think you are suggesting, is that we rename gnulib files, and edit their contents, after copying them from gnulib into Emacs. But this will break the existing "make sync-from-gnulib", or require "make sync-from-gnulib" to be considerably more complicated. The renaming and copying is needed only on MS-DOS; it's not needed for any other platform. It makes sense to do it only on MS-DOS. This will simplify maintenance on non-MS-DOS platforms; for example, it will make it easier to propagate fixes from Emacs back to gnulib. >> Also, the problem of non-8+3 file names does not seem to be limited >> to gnulib-derived files. > > Yes, they are limited to gnulib-derived files. If you mean Org, I'm > sure those files will be renamed. I meant all the other files that have 8+3 issues. These are all problems, even if the solutions differ for different cases. > Who is "we" here, I wonder. I can write the above scripts for Emacs. The ideas can be propagated into GDB later, as needed.
