delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/03/01:07:22

From: pjfarley AT dorsai DOT org (Peter J. Farley III)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Rebuilding gcc - "c-parse.gperf" not found
Date: Wed, 03 Sep 1997 02:30:11 GMT
Organization: None
Lines: 64
Message-ID: <340cc654.3895823@snews.zippo.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970902185836 DOT 22592B-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>
>That is exactly what I had in mind.  The zip should include
>configure.bat, not configur.bat.  Then, when you unzip it on non-LFN
>platform, you get configur.bat which will work (since non-LFN
>platforms silently truncate excess characters), while on LFN
>platforms, Make will find the full-length configure.bat and be happy
>also.
>
>That's why I said that the _zip_ file is not LFN-clean.

My misunderstanding, sorry.  I believe I'm starting to agree with you,
after my experiences so far.

>> I will, indeed notify DJ of everything I find.  I'm also writing a
>> Gawk program to scan through the makefile and clean all the long names
>> to 8.3, with a double-check to see that the 8.3 actually exists before
>> performing the rename.
>
>IMHO, this is the wrong way of achieving the goal.  The file names
>should be stored with their full length in the zip file, not
>truncated.  If you truncate them, you will need to make too many
>changes in the Makefile, which might be a pain when you use the
>original Unix Makefile with minimal changes.

Agreed, when I had time to reflect on what you say.  But I can just as
easily do the following:  Find all the long names in the makefile that
have *only* shortened real file names, and rename the short names to
the long ones.  I'll try it out and see how much damage I can
do...<g>.

>> 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.  OTOH, I'm not afraid of the long one, either.
On the gripping hand, I have since tried LFN=n, and it did help, a
little.  But there are still problems (see my next post to the forum,
they're not entirely relevant here), even booting back to DOS 6.22 and
QEMM 7.5.  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.

>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?)  Now, all we have to do is convince DJ
that this is the way to go ... (I know, two chances, slim and none,
right?)  Hmm-m-m.  Maybe we can all (or at least a few of us) chip in
and buy DJ a copy of Win95 (just for development efforts, you
understand, not to really *use*...<g>) so he could do that for we
long-name folk.

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

- Raw text -


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