Date:	Thu, 6 Jul 2000 10:05:19 -0400 (EDT)
From:	Frank Donahoe <fdonahoe AT wilkes1 DOT wilkes DOT edu>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	DJGPP List <djgpp AT delorie DOT com>
Subject:	Re: building flex 2.5.4
In-Reply-To:	<Pine.SUN.3.91.1000705092218.10925G-100000@is>
Message-ID:	<Pine.A32.3.96.1000706094809.10430B-100000@wilkes1.wilkes.edu>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 5 Jul 2000, Eli Zaretskii wrote:

> 
> On Tue, 4 Jul 2000, Frank Donahoe wrote:
> 
> > The failure of the build process with LFN enabled is because an
> > intermediate file `y.tab.c' is generated while the supplied Makefile
> > expects to see `y_tab.c'.
> 
> What version of Bison do you have installed?  I'm guessing that this
> problem appeared because the DJGPP port of the latest Bison produces
> Unix-style y.tab.c files under LFN, whereas the Bison port used for
> the original Flex build always produced y_tab.c.
> 
Your guess is accurate. I'm using bison from "bsn128b.zip".

> > Expect to use the supplied source under plain DOS or when LFN are
> > disabled.
> 
> I think this is not a good idea.  A better one would be to modify the
> Makefile to always DTRT.  For example:
> 
>     parse.c: parse.y
> 	    $(YACC) -d $(srcdir)/parse.y
> +	    @if exist y.tab.c ren y.tab.c y_tab.c
> +	    @if exist y.tab.h ren y.tab.h y_tab.h
> 	    @sed '/extern char.*malloc/d' <y_tab.c >parse.tmp
> 	    @mv parse.tmp parse.c
> 	    @mv y_tab.h parse.h
> 	    @rm -f y_tab.c
> 
> The two lines marked with a plus sign + at the left margin are
> additions to the distributed Makefile.  The file djgpp.sed should be
> changed accordingly, to produce these lines when configur.bat edits
> Makefile.in into Makefile.
> 
We tend to do things in the way we know how to do.  I would have to
study to get sed to insert those lines in the proper place in
`makefile.in'.  Instead, if it is our will to have bison handle
".tab" identically whether or not LFN are possible, thanks to Mark E.'s
provision of `diffs.dos' with "bsn128s.zip" I can see how to eliminate
this new feature in bison.

Regards
Frank

- Raw text -