www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/11/06:34:43

Date: Thu, 11 Sep 1997 13:34:31 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Peter J. Farley III" <pjfarley AT dorsai DOT org>
cc: djgpp AT delorie DOT com
Subject: Re: Suggestion for future DJGPP development -- depend on bash
In-Reply-To: <3412fbc5.4046147@snews.zippo.com>
Message-ID: <Pine.SUN.3.91.970911131528.12859E-100000@is>
MIME-Version: 1.0

On Sun, 7 Sep 1997, Peter J. Farley III wrote:

> I have downloaded the FSF copy of gcc-2.7.2.3, and there is no file in
> that package called "Makefile.in.in", only "Makefile.in".

Other packages have such files.  In fact, every package that supports 
internationalization (aka i18n) has such a file in the `po' directory.

> OTOH, there *are* a lot of names in the package that are not unique in
> the first eight characters.  DJ dealt with these very constructively
> by shortening common prefixes like "stamp-" to "s-" or "st-", "tmp-"
> to "t-", etc.  That can be done on an automated basis, if needed, as
> part of a non-LFN implementation.

IMHO, this should be reported to the package maintainer as a bug that 
needs to be corrected.  There should be no problems in changing these 
names to be unique in the first 8 characters.

> Not a disadvantage at all, if you think about it.  Anyone who is brave
> (or foolhardy) enough to attempt a rebuild from source can, I believe,
> be expected to have the entire environment available.  Rebuilding from
> source is not trivial under any circumstances, so I do not believe it
> is too much to ask that the required toolset be expected to be
> available for source rebuilds.

With all due respect, I disagree.  The more auxiliary tools you require,
the more risk that something will go wrong with them.  People might have
old ports, non-DJGPP ports, or incompatible programs with the same names. 
Or they might set up the tools incorrectly.  It is a nightmare to solve
problems due to such snafus when an angry user tells you (from the other
side of the globe) that your package won't build on their system. 

Look how religiously do GNU people stick to tools that are available on 
all platforms.  Using your argument, they would require people to install 
GNU tools before building other packages.

In my view, using Bash and the rest of the utilities in DJGPP ports is
nothing but a strategic retreat.  It is justified (IMHO) only because the
alternatives are much worse.  Those who, like me, ported packages without
Bash, know how much energy is required just to generate the Makefiles from
Makefile.in, even for simple packages.  That energy is wasted, because the 
*real* porting is in making the code work on DOS. 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019