Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 16:54:16 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, address@hidden, 
>  address@hidden
> 
> 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?

This is the complexity I want to avoid.  Don't you think it's
complicated enough?  And how about the issue with using slashes in the
argument to djunpack? does that kind of subtlety mean something to
you?

> >   . Once the remapping is maintained by humans, it becomes unreliable.
> 
> No, not if it's checked.  Surely the check can be automated reliably.

The reliability of this is determined by the scripts that do it.
Scripts are written by people, who tend to err or miss something.

> > 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.

Only lisp/Makefile.in, which is not used when a release is built on
DOS (all the files are already compiled).

> 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.

More complications.  This means, for example, that to test an
arbitrary revision of the development tree, I will need to run
make-dist on Unix, create a tarball, copy it to a DOS machine, then
build, find problems, go back to the Unix machine, etc.

> > 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?

Maintenance.

> > 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.

How can instructions that need to be googled for be simple and
reliable?

> >> 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?

It's done by the ARI script.  All I know about the errors is that some
files still clash.

> 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

But the price will be unacceptable complications for MS-DOS.  No,
thanks, not unless we find a simpler way.

> >> 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.

Which ones?