Re: m4 files not unique in 8.3 environments

[Bruno Haible]

Eli Zaretskii wrote:
> > Is this the default Windows configuration? Or about which configuration
> > are you talking?
>
> It happens if one disables name-numeric-tails.  Which is necessary if
> one wants the same installation to work on both DOS and Windows.

When a GNU program, built as a DJGPP binary, is run on Windows, it suffers
from the horrible hacks inside Windows that were made to support the
long + short filenames at the same time. And from the limitations of the
DOS API vs. the Win32 API. Therefore for running programs on Windows,
nowadays mingw is the platform of choice.

Then, if you make DJGPP binaries only for running on DOS, you don't need
to disables name-numeric-tails.

> > > Even if the DJGPP port of gettext itself is not actively maintained,
> > > the gettext files do wind up in other packages that use GNU Gettext.
> > > (That's how Paul became acquainted with this issue.)
> >
> > These packages can use a fnchange.lst file
>
> They could

OK, then please use a fnchange.lst file.

> why should it be such a big problem.  They aren't magic file names,
> are they?

They aren't magic filenames. But there has to be a limit of extra effort
spent on non-mainstream platforms.

BeOS was released in 2000. In 2002, Paul Eggert made changes in gnulib
that were suboptimal for BeOS. (I mean the mbstate_t workarounds.)

AIX 3 was released in 1994. In 2004, Paul Eggert made changes in gnulib
that were suboptimal for AIX 3. (I mean the #pragma alloca.)

DJGPP was released in ca. 1990, and became obsolete in 1995. I'm making
changes that are suboptimal for DJGPP in 2002/2005.

Please realise that throwing away support for old platforms allows for
filenames and code to becomes cleaner and more natural:
  - Writing foo.html instead of foo.htm (or foo.lisp instead of foo.lsp)
    expresses more clearly the content type of the file.
  - Assuming that pipes are really pipes and not temporary files allow
    some kinds of inter-process communications.
  - Assuming the machine has more than 4 MB of RAM (such as a Sun3) allows
    libiconv's code to be written the way it is.
  - etc.

Bruno