From:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization:	Darmstadt University of Technology
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Thu, 13 Sep 2001 16:24:19 +0200
Subject:	Re: ANNOUNCE: DJGPP port of GNU Bison 1.29 uploaded
CC:	djgpp-workers AT delorie DOT com
References:	<200109121757 DOT NAA27738 AT delorie DOT com>
In-reply-to:	<Pine.SUN.3.91.1010913083700.28956B-100000@is>
X-mailer:	Pegasus Mail for Windows (v2.54DE)
Message-ID:	<70603045F88@HRZ1.hrz.tu-darmstadt.de>
Reply-To:	djgpp-workers AT delorie DOT com

On Thu, 13 Sep 2001 Eli Zaretskii wrote:
> I can't say I'm happy with this change.  It could easily cause subtle 
> problems for those who don't follow instructions.  It also means removing 
> these lines from djgpp.env in the next DJGPP release means we could break
> Bison for people who don't upgrade Bison when they download djdev204.zip.
The canonical place to install the parser files is %DJDIR%/share/bison and
IMHO djgpp's bison port should follow this.
IMHO this change is natural and not arbitrary. I have inspected the readme
file of bsn128 to see how this problem has been handle there. This is a quote
from the readme file:

This port puts the files 'bison.sim' and 'bison.hai' into the
'%DJDIR%/lib' and '%DJDIR%/share' directories. '%DJDIR%/lib' is the
location used by past ports of Bison and is the location forced by
DJGPP 2.03's djgpp.env. But '%DJDIR/share' is the location preferred
by Bison and which will be reflected in DJGPP 2.04's djgpp.env. To make
the transiton now, delete the part of djgpp.env that looks like this:

[bison]
BISON_HAIRY=%DJDIR%/lib/bison.hai
BISON_SIMPLE=%DJDIR%/lib/bison.sim

then delete 'lib/bison.sim' and 'lib/bison.hai' from the top of your
DJGPP tree.
---------End of qoute ------------

Is this politics no longer true? Has this been given up?
Will DJGPP 2.04's djgpp.env continue making the same assumptions
about bison than DJGPP 2.03's djgpp.env has done?

I have also inspected the worker list to see what has been said
about this issue in those days.

From: "Mark E." <snowball3 AT bigfoot DOT com>
To: djgpp-workers AT delorie DOT com
On Tue, 29 Feb 2000, Mark E. wrote:
> Bison's defaults work just fine, so why not get rid of the bison section in djgpp.env?
>
> *** djgpp.env.orig	Fri Dec 24 15:19:04 1999
> --- djgpp.env	Tue Feb 29 23:37:30 2000
> *************** DJDIR=%:/>DJGPP%
> *** 12,21 ****
>   +TEXMFMAIN=%DJDIR%/share/texmf
>   +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
>   C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/include
> --- 12,17 ----


On Thu, 2 Mar 2000, Eli Zaretskii wrote:
> On Tue, 29 Feb 2000, Mark E. wrote:
>
> Bison's defaults work just fine, so why not get rid of the bison section in djgpp.env?
>
> Some people might still have an old port of Bison.  However, we could 
> indeed safely assume that by the time v2.04 is out, they will all
> switch ;-).
>
> Thanks!

There is no ofending intention here. I know that everybody forgets what he
has said years ago. After reading the mails in the worker list I have assumed
that the bison specific entries in djgpp.env would be removed in 2.04.

To clarify the issue: I have submitted patches for djgpp build-in support
to Akim D. This port works with exactely those patches. This implies that if
the port behaviour is not welcome at all or considered brocken, then the
build-in support for future bison versions is also brocken and new patches
must be submitted to the GNU mantainer. IMHO, backward compatibility should
be given up and the canonical way stipulated by the GNU Makefiles should be
accepted by DJGPP. This will allow real DJGPP build-out-of-the-box because
the install target and all outher releated parser file issues become DJGPP
independent. We have a /share subdir and we should use it. Netherless, it is
not my intention to create difficulties. If the old way (installing the
parser files in the /lib subdir and use env. variables to point to them) is
prefered, then let me know and I will change the port and submite new patches
to Akim. I would seriuosly welcome any design rules about this port.
IMHO this should be decided now once and for all.

BTW, the bison entries looks like this:
[bison]
BISON_HAIRY=%DJDIR%/lib/bison.hai
BISON_SIMPLE=%DJDIR%/lib/bison.sim

This does not allow the user to use the env. variables to select
his prefered parser files. The entries, if retained at all, shuold
look like this:
[bison]
+BISON_HAIRY=%DJDIR%/lib/bison.hai
+BISON_SIMPLE=%DJDIR%/lib/bison.sim


Regards,
Guerrero, Juan Manuel

- Raw text -