Subject: Re: ANNOUNCE: DJGPP port of GNU Bison 1.29 uploaded From: Tim Van Holder To: djgpp-workers AT delorie DOT com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.13.99+cvs.2001.09.11.22.18 (Preview Release) Date: 13 Sep 2001 12:59:40 +0200 Message-Id: <1000378781.32324.36.camel@bender.falconsoft.be> Mime-Version: 1.0 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 Thu, 2001-09-13 at 11:16, Eli Zaretskii wrote: > > On 13 Sep 2001, Tim Van Holder wrote: > > > On Thu, 2001-09-13 at 08:39, 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. > > > > > > Why was this change necessary? > > > > Probably to fall in line with the canonical GNU file locations (i.e. > > $prefix/share/$package for package-specific files); and having /dev/env > > support makes that possible. > > Having these settings in djgpp.env was probably a mistake anyway; > > overrides like that always make creating a cleaner port harder (for > > exactly the reasons you give). > > You misunderstood: by ``this change'' I meant the directory into which > the parsers install when you unzip bsnNNNb.zip, not some change in the I know - like I said, bison probably uses $pkgdatadir ($prefix/share/$package) for the parsers. The DJGPP binary package was subsequently built from the results of a 'make install', which makes sense (having different layouts can get confusing and annoying if you use the same tools under different environments). > sources. How we package the binary distribution is entirely under our > control, and don't make the porting job any harder. I was thinking along the lines that once the tarball builds out-of-the-box, you'd have to do extra work after a 'make install' in order to put things in the old, non-standard locations. But I guess it might be acceptable in cases like this to set the relevant Makefile.am/configure.ac variable to use the old location for the DJGPP port (in this case, using $libdir instead of $pkgdatadir).