X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Wed, 20 Feb 2002 11:10:32 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc: djgpp-workers AT delorie DOT com,
   Juan Manuel Guerrero <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Subject: Re: bison and djgpp.env
In-Reply-To: <1014193306.14698.21.camel@bender.falconsoft.be>
Message-ID: <Pine.SUN.3.91.1020220110537.21448N@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 20 Feb 2002, Tim Van Holder wrote:

> The problem is that it points to a wrong path ($DJDIR/lib instead of
> $DJDIR/share/bison) - a basic difference between bison 1.28 and later.

This was discussed with Juan, and I believe we have it solved without 
hurting backwards compatibility.

> The point is that bison now uses pkgdatadir (i.e. share/bison, not lib) as
> target location for its support files.  So someone building a recent bison,
> would get a non-functional bison, unless they either actively override
> the default settings for BISON_{HAIRY,SIMPLE} djgpp.env provides, or
> place the new skeletons in the old, deprecated, location.

I believe the latter alternative is what Juan does in the ported package.

> The only reason we have these variables in djgpp.env in the first place
> is because pre-2.03 apps had hardcoded paths (using the build system's
> DJDIR as $prefix).  Since 2.03's /dev/env support, this is no longer
> needed.

It's okay for newer versions of Bison not to look at these variables, or 
to look inside /dev/env/DJDIR/share first.  But older ports should 
continue to work with newer djdev releases, IMHO.

> I agree that people don't need to update everything, but I do
> feel it's reasonable to require them to have to use a 2.03-based bison

I don't agree that it's reasonable.  Users could have their reasons for 
not upgrading, and we shouldn't second-guess them.