www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/11/04:51:20

From: pjfarley AT dorsai DOT org (Peter J. Farley III)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Suggestion for future DJGPP development -- depend on bash
Date: Sun, 07 Sep 1997 19:23:08 GMT
Organization: None
Lines: 40
Message-ID: <3412fbc5.4046147@snews.zippo.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970907133317 DOT 2248Q-100000 AT is>
NNTP-Posting-Host: news.newsdawg.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
<Snipped>
>I fail to see how using Bash will resolve LFN-related problems.  These 
>are two different issues.  Filenames like Makefile.in.in will always fail 
>on plain DOS, no matter which shell do you use, because such names are 
>simply illegal on DOS.  Every file-related DOS system call fails when you 
>feed it with such a name.

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".  Perhaps
that helps solve at least one knotty problem.

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.

For example, instead of just one DJGPP configuration, there could be
multiples based on the DOS version:  "i386-go32-msdos-7" for Win95/DOS
boxes, "i386-go32-msdos-6" for regular DOS, "i386-go32-opendos" for
the new version of opendos with LFN support, etc.

<Snipped>
>One obvious disadvantage is that whoever needs to build a package has a 
>whole slew of utilities to install on their machine.
>
>I'm not telling that this disadvantage is prohibitive (the fact is that 
>most of the latest ports I've done used Bash and the original configure 
>scripts), but we shouldn't forget it nevertheless.

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.

----------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org)

- Raw text -


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