Date: Tue, 30 Jun 1998 11:25:07 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Some notes about DJDEV202.ZIP
In-Reply-To: <Pine.SUN.3.91.980630101200.6274C-100000@is>
Message-ID: <Pine.A32.3.91.980630101421.72996A-100000@ieva05.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk



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