Mail Archives: djgpp-workers/1998/06/30/04:27:06
On Tue, 30 Jun 1998, Eli Zaretskii wrote:
>
> On Mon, 29 Jun 1998, Andris Pavenis wrote:
>
> > > Isn't there any other way to make both 2.7.2 and 2.8.x be happy? Maybe
> > > some other environment variable that can be used differently by each
> > > version?
> >
> > One of thing could be adding support of exceptions to crt0.o
> > instead of using additional file crtf.o as it is done in gcc281b.zip.
> > However this will cause MANY problems for many poeple as they
> > will need immediatelly replace specs and djgpp.djl files supplied
> > with gcc281b.zip.
>
> Too gross and risky, IMHO.
I agree,
>
> How about actually making %DJDIR%/lib/gcc-lib/2.81/lib be part of
> LIBRARY_PATH in v2.02's DJGPP.ENV? For example:
>
> LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib/gcc-lib/2.81/lib;%DJDIR%/lib;%DJDIR%/contrib/grx20/lib
>
I'm against this. This solution will be useless when gcc-2.8.2 will be out.
(or some other version). The same will be when Andrew will release port
of pgcc-1.0.3.
> If this works, then gcc 2.7.2 will just try to search a non-existent
> directory and settle for %DJDIR%/lib, while gcc 2.8.1 will happily
> find its own directory.
>
> The only situation when this will need tweaking is for those who want
> to have dual 2.7.2/2.8.1 installation. But those will need to edit
> DJGPP.ENV anyway.
>
One thing that is missing from packages in DJGPP distribution is possibility
to run some script (.bat file or something else) when some package is
unpacked. I have worked with LINUX Slackware distribution for some time
and see that this possibility is very good. For example
installpkg ncurses.tgz
unpacks ncurses package and runs installation script if one exist in
package. And
removepkg ncurses
removes package (checking at first for files that should not be deleted
because they are needed for other packages)
I understand that similar feature is not so easy to implement in DJGPP,
but it would be nice to have something similar. I see at least some
places where it could be usefull (the list is not full, of course):
- editting info/dir to include pointer to info files for the
newly installed package
- automatic updating RHIDE.ENV when this is really needed.
I think situation with gcc-2.7.2.1 and gcc-2.8.1 is such.
I'm afraid that attempt to use only one configuration file for all
possible situations is much too restrictive. I think the right way could
be to make installation (and upgrading) DJGPP as possible user friendly.
But we should take into account that many users does not read readme files
even when they are stuck.
Andris
- Raw text -