Date: Wed, 19 Jan 2000 17:46:56 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: make depend In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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__.