Mail Archives: djgpp-workers/2001/09/13/07:00:38
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).
- Raw text -