Mail Archives: djgpp-workers/2002/02/20/13:28:43
> Please make the bison changes. I have no cvs write access and
> this change is essential.
I will update CVS when I get a chance and we agree exactly what to do...
> It should be noticed that ENSCRIPT_LIBRARY points to the wrong place.
> enscript 1.6.1 and enscript 1.6.2 places their files in the canonical places:
> /dev/env/DJDIR/etc for enscript.cfg and
> /dev/env/DJDIR/share/enscript for the AFM fonts.
> AFAIK enscript 1.5.0 has been removed from simtel.net, so the ENSCRIPT_LIBRARY
> is no longer needed. IMHO this entry should be removed or it should point
> to the right place.
I assume the old versions need this, however, so if someone has an old
version downloaded/installed I would not want to break that install by
removing the environment variable (at least not in a 2.03 refresh). Adding
a + in front of the variable seems the right thing in any case. If the
old environment variable doesn't hurt anything in new versions I would rather
document and leave it.
> OFYI:
> Bison ports from 1.29 to 1.33 install their skeleton files in the canonical
> place: /dev/env/DJDIR/share/bison and at the same time as bison.{sim, hai} in
> /dev/env/DJDIR/lib. This is needed to avoid changes in djgpp.env. Non of these
> ports will stop working if the BISON_{SIMPLE, HAIRY} entries are removed from
> djgpp.env. They all have been configured with the canonical path.
> The only port that may stop working is bison 1.28. But even this port can be
> recompiled with it own canonical path. If such an updated port is uploaded
> to simtelnet there would be no longer the need of an bison specific entry in
> djgpp.env.
There is still the problem of old distributions - so I believe it's
appropriate to keep the variables there for quite some time.
> If the size of the binaries, due to NLS, is an issue, then bison 1.32 can be
> recompiled and uploaded without NLS and bison 1.33 with NLS. But that is
> only a suggestion.
It's not just the binary sizes - it's the memory footprint. bison 1.28 is
less than 128K in size, bison 1.32 with NLS is over 1Mb in size. On a
small memory machine that would completely kill the usability.
But many people want and need NLS functionality and have enough memory
such that the extra 1Mb per image doesn't bother them. Trying to have
multiple distributions will just confuse people.
I believe we need to figure out how to put the iconv stuff into a DXE
image. That image should also have a "stub" version available which
does the non-NLS thing so the same distribution works with or without.
I've got the technology sitting on my disk at home, but I haven't had
time to finish it.
(My thoughts would be to have the code linked in the image include the
"do nothing" functionality. If it finds the DXE it calls it for those
services. By installing the DXE you automatically upgrade images
to use it).
- Raw text -