Date:	Tue, 25 May 1999 13:20:56 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	robert DOT van DOT der DOT boon AT nl DOT pwcglobal DOT com
cc:	"Mark E. _" <snowball3 AT bigfoot DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: SFN patches
In-Reply-To:	<8025677C.002FB9EA.00@intleursmtp10.uk.pw.com>
Message-ID:	<Pine.SUN.3.91.990525130321.4081A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 25 May 1999 robert DOT van DOT der DOT boon AT nl DOT pwcglobal DOT com wrote:

> >From what you've noted, I was thinking it would be a lot of work to make
> >Bash SFN buildable.
> 
> That was not quite it. It were a couple of issues, not too much work...

My experience is that usually supporting non-LFN platforms is not hard 
at all.  The small number of problems posted here is typical.  That's why 
I always recommend to include support for non-LFN platforms.

> - The examples directory is not SFN-clean. Do we want to fix that?

My recommendation would be to fix everything in sight.  You can never 
know what files would a DJGPP user want to see/use.  Unless the 
maintainers resist renaming files (most of them won't), there should be 
no reason to keep problematic names.  In extreme cases, you can include a 
file-name change file in the distribution that could be submitted to 
DJTAR so that it automatically renames files while unpacking.

> - '-o outputilename' is not a standard option. (SunOS-yacc on our uni
> silently ignores it, and still creates y.tab.c)

For this and other reasons, I would suggest to solve the problem with 
y.tab.* differently.  Instead of forcing the parser-generator to produce 
a certain file name, rename the result, something like this (this is 
directly from TeX/Web2C distribution):

y_tab.c y_tab.h: web2c.y
        $(YACC) -d -v $(srcdir)/web2c.y
        -test -f y.tab.c && mv -f y.tab.c y_tab.c
        -test -f y.tab.h && mv -f y.tab.h y_tab.h

This has several advantages:

 - it works on Unix as well as on DOS/Windows, and thus the maintainers 
   will have less problems including it in the official distribution;
 - it works automagically both on LFN and non-LFN platforms, because Bison
   produces y.tab.* under LFN and y_tab.* without LFN;
 - it will work with Yacc as well, even if somebody uses a version ported 
   to DOS (which produces y_tab.* also).
 - if a file y.tab.c is included in the GNU source distribution, DJTAR 
   will automatically rename it to y_tab.c when LFN support is 
   unavailable, so the whole thing will still work unaltered.

> And by the way, what are the chances of getting all our
> changes into the official distribution?

Without knowing diddley-squat about the Bash maintainers, I would guess 
the chances are pretty good.  I have yet to see a single GNU maintainer 
who would decline clean patches to support another platform (well, 
actually I already saw one such person, but that was a clear exception).

- Raw text -