Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 00:48:12 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
> instead of doing the stuff I mentioned before the tarball is
> created, we can add a shell script to be run after the tarball is
> extracted.  For example, on MS-DOS the c++defs.h file is
> automatically renamed to cxxdefs.h by the extractor, so the script
> can uniformly substitute "cxxdefs.h" for "c++defs.h" in all the text
> files.  Hopefully a similar idea works for all the other files with
> non-MS-DOS names.

The magic coded into the extractor utility is limited.  It indeed
handles file names with `+' in them, but does not handle arbitrary
file names with multiple dots as a human would.  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).

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

> I assume that the "configure" procedure for MS-DOS is already
> different

Yes, see config.bat in the top-level directory.  But that's not the
issue here.

> > The files in m4/ still matter because you need to unpack the tarball,
> > and the utility that does that won't silently overwrite files due to
> > file-name clashes.
> 
> 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.

> just as I assume they already ignore the diagnostics for the files
> whose names start with ".".

No, there are no diagnostics for these conversions, they are done
silently.