Message-Id: <200002242322.SAA31756@delorie.com>
From: "Mark E." <snowball3 AT bigfoot DOT com>
To: Eli Zaretskii <eliz AT delorie DOT com>, djgpp-workers AT delorie DOT com
Date: Thu, 24 Feb 2000 18:30:56 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: ANNOUNCE: Bison 1.28 ported to DJGPP
In-reply-to: <200002242113.QAA20735@indy.delorie.com>
References: <200002231814 DOT NAA11884 AT delorie DOT com> (snowball3 AT bigfoot DOT com)
X-mailer: Pegasus Mail for Win32 (v3.12a)
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

>  1. The source distributions includes file names which are invalid on
>     MSDOS: intl/po2tbl.sed.in and po/Makefile.in.in.  This prevents
>     the distribution from configuring and building on MSDOS (building
>     without reconfiguring does work).

Sorry about that. I'll correct this when I can.

>  2. Some of the files in the binary distribution are long
>     (e.g. REFERENCES), but others, like bison.sim and bison.inf, are
>     truncated.  Why?

bison.sim needs to work in both environments. REFERENCES is just a text file 
so it doesn't matter if it's truncated.
 
>  3. What is the file bison.s1 in the source distribution?

During the build process, bison.s1 is copied to bison.simple.

>     the old files, why is it a good idea to disable the environment
>     variables BISON_SIMPLE and BISON_HAIRY?  This makes DJGPP the only
>     platform which doesn't support these variables.  If I'm not
>     mistaken, there's no other way for a user to control what parser
>     skeleton will be used except through these variables, so there's no
>     way, e.g., to test a different version of these files without
>     overwriting the standard ones.

But djgpp.env doesn't let the user control them anyway so it's already out of 
their hands. This can be corrected for DJGPP 2.04 by applying this patch to 
djgpp.env:

*** djgpp.env.orig	Fri Dec 24 15:19:04 1999
--- djgpp.env	Thu Feb 24 17:59:36 2000
*************** DJDIR=%:/>DJGPP%
*** 13,20 ****
  +GO32STUB=%DJDIR%/bin/stubify.exe
  
  [bison]
! BISON_HAIRY=%DJDIR%/lib/bison.hai
! BISON_SIMPLE=%DJDIR%/lib/bison.sim
  
  [cpp]
  CPLUS_INCLUDE_PATH=%/>;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/include
--- 13,20 ----
  +GO32STUB=%DJDIR%/bin/stubify.exe
  
  [bison]
! +BISON_HAIRY=%DJDIR%/share/bison.hai
! +BISON_SIMPLE=%DJDIR%/share/bison.sim
  
  [cpp]
  CPLUS_INCLUDE_PATH=%/>;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/include

However, now that I've thought about it, it does seem unfair to those using 
it standalone (without djgpp.env). I will ponder on a solution after dealing 
with binutils.

>     All this just to correct the decision made years ago to put the
>     files into the lib subdirectory (because share didn't yet exist)?

Well, mistakes do deserv be corrected, yes?