Date:	Wed, 19 Jan 2000 17:46:56 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: make depend
In-Reply-To:	<Pine.A41.4.05.10001191549180.72182-100000@ieva01.lanet.lv>
Message-ID:	<Pine.SUN.3.91.1000119173602.13343I@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 19 Jan 2000, Andris Pavenis wrote:

> I think that changing library version some problems with existing 
> software. I saw it very well when upgraded Linux from libc-5 to glibc-2.1
> almost a year ago.

We don't need to learn from Linux: it's not the best place to learn about 
back-compatibility (IMHO).  I just finished a 3-week-long session of mail 
exchange with some user who couldn't compile Emacs 19.34 with the latest 
glibc on Linux, due to an incompatible change in glibc system headers.
And this happens with Emacs, not some subtle third-grade software, and 
with version 19.34 which is still widely used!

IMHO, Linux is not suited well for novices.  It requires hacker's mindset 
and some hacking experience.  DJGPP cannot count on that; the bulk of our 
users aren't like that.

> Our current hack we're using to get DJGPP_MINOR defined is incompatible
> with DJGPP v2.00 and v2.01. If we'll avoid this hack and avoid 
> defining this macro in user code, we should not get too serious problems.

I said it in the past, including in this thread, and I will say it again: 
the cleanest way to get this issue resolved without breaking any code, 
past or future, would be for GCC or cpp to have an environment variable 
that can be set from DJGPP.ENV, and which will then have the effect of 
-D__DJGPP_MINOR__=whatever.  Then each djdev release will change that as 
needed, and we can safely put this issue behind us, once and for all.

> I think currently such thing could be done by poeple releasing ports
> of different packages for DJGPP to provide that we'll not break
> additional things (simply by removing this hack from specs).

DJGPP continues to evolve; new features are added all the time.  It is 
inevitable that people who port packages will want to use those features, 
and they will then need __DJGPP_MINOR__.  You are suggesting a solution 
that depends on vigilance on the part of those who port packages.  In 
contrast, I'm looking for a solution that will magically work without any 
need to remember the Right Way of using __DJGPP_MINOR__.

- Raw text -