automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: backward compatability of tools


From: Dr. David Kirkby
Subject: Re: backward compatability of tools
Date: Tue, 18 Feb 2003 10:18:17 +0000

Paul Eggert wrote:
> 
> "Dr. David Kirkby" <address@hidden> writes:
> 
> > SunOs 4.1.4
> 
> Sun has been withdrawing support for that OS.  Since September 2000
> Sun has not issued patches for new bugs in that operating system.  On
> September 30, Sun will further transition SunOS 4.1.4 to "custom
> quote" level, which means you will need to spend a lot of money (and
> have service division VP approval!)  in order to get a bug fixed.

I take your point, although you are saying it is still an operating
system supported by Sun. They are not issuing bug fixes, but it is
still supported - for a few months at least. 

 > For quite some time now, the vast majority of bug reports that I've
> gotten from SunOS 4.x users are from people who are doing portability
> checking.  In other words, they don't need the software themselves;
> they just think that other people might need the software.

As I stated at the beginning, portability testing was why I was doing
this under SunOs 4.1.4. I don't need to run the software on a 10 year
old hardware/software, when I own a Sun Ultra 80 with 4 CPUs and 4 Gb
of RAM, running the latest Solaris release. 

However, I do feel there is some merit in testing software on
platforms even if you, *nor anyone else*, wants to use it on those
platforms! That may sound a stupid statement, but is not quite so
stupid as it first sounds. There may *real bugs* that become evident
under SunOs 4.1.4, that are not evident on more modern platforms that
I personally have access to, but otheres do use. Certainly experience
has shown the software to have real bugs which only affect Dec Alphas,
only seem to affect gcc-2.8.1, or only seem to affect Windoze XP, yet
in each case the bugs were real - not just silly things like ignoring
the return value of printf. 

I know Lint is useful in this respect, but I do feel trying to change
code to make lint happy is likely to introduce more bugs than it
solves. In contrast, real bugs found on a particular platform might
well affect others now or in the future.

If developers of engineering tools A and B try to ensure backward
compatibility whilst developers of engineering tools C and D don't,
that is their choice. Tools A and B work on old machines, whilst C and
D don't. In contrast, once developers of development tools such as
autoconf and automake break backward compatibility, it screws it up
for ALL developers, so now engineering tools A and B stop working,
despite the efforts of their developers. Hence I feel there is some
moral responsibility for developers of *development tools* like
autoconf and automake to avoid breaking backward compatibility if
*reasonably* practical. 

Clearly my views seem to be in a minority!!

-- 
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]