Re: Files from gnulib

[Paul Eggert]

On 01/25/11 03:24, Eli Zaretskii wrote:

> It uses some
> convoluted algorithm to replace the extra dot with a `_' or a `-';
> sometimes it replaces the first dot, sometimes the second.  The
> results are often unpredictable or surprising, especially if, as it
> often happens, the modified names also clash in the 8+3 namespace (see
> below).

The results may seem convoluted, but I doubt whether they are actually
unpredictable.  I suspect we can accommodate whatever programmatic scheme
djtar defaults to.  Or we can tell djtar to use our own scheme, as
discussed below.

>> That's OK.  People can ignore those diagnostics
> 
> The result is not ignorable diagnostics, but a prompt for the user to
> provide an alternate name.  Since the user does not generally know
> whether these files are needed by the build, she will not be able to
> deal with the prompt.

We already provide instructions for people who want to build Emacs
on MS-DOS platforms.  Our instructions can be expanded slightly
to tell them how to extract the files in the first place, and how
to deal with such prompts.  They can be asked to just type RETURN,
for example.

Or, if that's too much trouble, the MS-DOS build instructions could
instead tell people to fetch a small file "emacs-25.chg", and then
execute

   djtar -n emacs-25.chg emacs-25.tgz

where emacs-25.chg is a list of desired file name conversions.
That is not much trouble, and it also addresses the extraction
name-change issues that have been raised so far.  If we don't
want to distribute this small file separately, we can bundle it
as part of the Emacs tarball, and give instructions on how to
extract it separately first.

> So going this way means a much more complex and error-prone
> arrangement than a one-time rename of a small number of files.

It is a bit more complex and error-prone for MS-DOS, yes.  But
it has the advantage of compartmentalizing the MS-DOS restrictions
into the MS-DOS build instructions, rather than having these restrictions
spread to Emacs more generally, where they complicate software
integration efforts there.  There is a significant advantage to
modularization and separation of concerns, one that outweighs minor
increases in complexity for individual components.