bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4 files not unique in 8.3 environments


From: Bruno Haible
Subject: Re: m4 files not unique in 8.3 environments
Date: Tue, 1 Mar 2005 13:27:29 +0100
User-agent: KMail/1.5

Eli,

> I didn't ask anyone to waste their brain cells: that's what I'm here
> for.  I found the problem, analyzed it, and suggested a simple
> solution: to rename 2 files.  If my suggestion were accepted, instead
> of starting a dispute, we could be off doing more important things
> already.

You proposed one solution, although at least two solutions were possible
(1. renaming, 2. fnchange.lst).

I don't accept your proposed solution, because

  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.

  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.

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

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.

                  Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]