Date: Tue, 25 May 1999 13:20:56 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: robert DOT van DOT der DOT boon AT nl DOT pwcglobal DOT com cc: "Mark E. _" , djgpp-workers AT delorie DOT com Subject: Re: SFN patches In-Reply-To: <8025677C.002FB9EA.00@intleursmtp10.uk.pw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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).