Re: m4 files not unique in 8.3 environments

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Date: Tue, 1 Mar 2005 13:27:29 +0100
> Cc: address@hidden, address@hidden
> 
> You proposed one solution, although at least two solutions were possible
> (1. renaming, 2. fnchange.lst).

I explained elsewhere in this thread why fnchange.lst type of solution
is in my opinion inappropriate for Make (and Paul Smith actually
mentioned something very similar in his mail).

>   1. Clarity of concepts is important to every user who unpacks the tar
>      file and looks in the source code. I have long enough used filenames
>      like "defstruc.lsp" that mutilate names and concepts. Now, when I
>      write an autoconf macro that deals with the PRI* macros in <inttypes.h>
>      I already make compromises by not calling the file
>           <inttypes.h>-PRI*.m4
>      (as it really ought to be) but rather
>           inttypes-pri.m4
>      Further mutilation of filenames would completely hide the purpose of
>      the file.

I didn't suggest to mutilate the file names, I suggested renaming
them.  Would a name such as pri-inttypes.m4 be acceptable?  If the
name comes from the phrase "PRI* macros in <inttypes.h>", then I think
pri-inttypes.m4 (or perhaps even pri-in-inttypes.m4) should be as
mnemonic as inttypes-pri.m4.

>   2. Platforms which were important in the past are less important nowadays.
>      The mainstream Unix platform since 1990 was the Sun4. Yet in gnulib
>      we stopped supporting it around 2 years ago. DJGPP was introduced
>      around 1990 as well. If you want to have it supported now, you (as a
>      group of users) need to invest some time in it. This has not happened:
>      As I already said, the DJGPP port of GNU gettext is orphaned for 3
>      years.

I was not talking about gettext, only about gettext-related files that
wind up in Make and other packages that support message catalogs.

> > What good is Free Software for if, instead of being kind and cooperative,
> > we adopt the ``my way or the highway'' style?
> 
> Free Software is free so that everyone can maintain his local forks, if
> he needs particular features or support for particular platforms.

Forcing people to fork without a very good reason is precisely ``the
highway'' attitude.

> Free Software, IMO, does not mean the duty to support platforms that are
> neither mainstream any more and that are either not easy to maintain or
> whose support conflicts with other goals. The GNU standards, node
> "System Portability", are quite explicit about which platforms are
> important for GNU packages.

While this is all true in principle, in practice most GNU packages,
including Emacs (maintained by Richard Stallman, who wrote and
maintains the GNU coding standards), do find ways to avoid the kind of
problems with file names that are similar to the case in point.

So evidently, given a little good will, solutions _can_ be found to
these problems without giving up neither principles nor coding
standards.  Can we do that here?