Date:	Thu, 4 Sep 1997 20:29:23 +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: Rebuilding gcc - "c-parse.gperf" not found
In-Reply-To:	<340cc654.3895823@snews.zippo.com>
Message-ID:	<Pine.SUN.3.91.970904202900.27525D-100000@is>
MIME-Version:	1.0

On Wed, 3 Sep 1997, Peter J. Farley III wrote:

> >> Another thought just occurred to me.  If I turn OFF LFN support, would
> >> that let the makefile work as-is?
> >
> >It won't work for every package.  Don't forget that Makefiles and
> >batch files sometimes call DOS commands like `copy', `ren' etc., and
> >these don't know about the LFN variable.  They always expect to see
> >the long file names.
> 
> But I was only asking for *this* package.  I'd much rather a shorter
> solution (LFN=n is a lot shorter than the gawk programming I suggested
> above) than a long one.

First, I doubt it's a shorter solution, since you still need to find
all the references to such names in the Makefile(s) and change them.
And second, I assumed that since you've posted to the news group, you
were talking about how this problem should be handled in future
releases, not about the quickest hack for this package/version only.
In the long run, IMHO, the zips should include the original long
names with minimal changes (see below).

> For example, LFN=n does not help the problem in the
> configur.bat file in the main directory calling the msdos .bat file
> "config\msdos\configure", when only "...\configur.bat" exists.

Exactly.  Make runs batch files by calling COMMAND.COM, and that
sucker doesn't know about LFN=n, it needs configure.bat and won't
settle for the truncated name, period.

In general, LFN=n should be a quick-and-dirty solution; if it works,
you are in luck, but it won't solve all LFN-related problems,
certainly not with large packages being built by complex Makefiles.
The issue is just too damn tricky to allow such a simple solution.
It's no accident that it took so many iterations to make it work
satisfactory in DJGPP, and I'm sure there are still some subtle
problems we didn't think about.

> >So the only way to make it work on both types of systems is to make
> >the zip file store long file names which don't conflict when they are
> >unzipped on non-LFN machine (for example Makefile.in.in should be
> >stored as Makefile.in-in).
> 
> Agreed, as I said earlier.  (But you *did* mean to say "... as
> Makefile.in.in", didn't you?)

No, I meant Makefile.in-in.  If you put Makefile.in.in into the zip,
it will (1) overwrite Makefile.in on non-LFN platforms and Windows 95
where NameNumericTail is set to zero, when you unzip the package; and
(2) cause trouble when Make is run on non-LFN platforms, since
Makefile.in.in is illegal name there and therefore it fails all
file-related libc functions.  This is one of the few cases where a
distribution ported to DJGPP should change the original name, so it
will work on all platforms supported by DJGPP.  (You also need to
change the Makefile rules that use Makefile.in.in; in the ports I've
made, this is done by the modified `configure' script when it creates
Makefile from Makefile.in.)

- Raw text -