Date: Thu, 24 Feb 2000 16:13:52 -0500 (EST)
Message-Id: <200002242113.QAA20735@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
CC: snowball3 AT bigfoot DOT com
In-reply-to: <200002231814.NAA11884@delorie.com> (snowball3@bigfoot.com)
Subject: Re: ANNOUNCE: Bison 1.28 ported to DJGPP
References:  <200002231814 DOT NAA11884 AT delorie DOT com>
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


> The DJGPP port of Bison 1.28 is available from SimTel mirrors.

Thanks!

A few comments about this port:

 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).

 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.inf might cause some trouble on LFN systems, because I'm not
    sure all Info readers look for .inf extension under LFN.  Versions
    of info.exe before 3.12 didn't, for example.

 3. What is the file bison.s1 in the source distribution?

 4. My greatest gripe is about the change of the directory where
    bison.simple and bison.hairy are installed.  Apart of the problems
    it might cause to those who don't read the docs and don't remove
    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.

    All this just to correct the decision made years ago to put the
    files into the lib subdirectory (because share didn't yet exist)?
    Seems like an awful lot to pay for tidying up the DJGPP
    installation tree.