From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: Eli Zaretskii 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: 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." 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