On Tue, 2005-07-19 at 20:07 +0200, Stepan Kasal wrote: > Hi, > > On Thu, Jul 14, 2005 at 12:19:26PM -0400, Sam Steingold wrote: > > > * David Boreham <qnivq_yvfg@xxxxxxxxxxx> [2005-07-14 08:42:46 -0700]: > > > Wouldn't it be easier to simply read the version number ? > ... > > isn't the whole idea of autoconf to avoid relying on version numbers? > > no, it isn't, thought it might sound so. > > Yes, you hear "test for features, not for version numbers". > The reasoning is like this: > Say that you observe a bug in latest "Fumix 7.1", which needs a workaround. > If you activate the workaround for Fumix >= 7.1, you might loose in several > cases: > 1) if "Fumix 7.2" will fix the bug > 2) if you encounter a patched version of "Fumix 7.1" which no longer has the bug > 3) if "Fumiris 2.0" will have the same bug > > So if we speak about a general feature, it's better to test for the feature > then to collect version intervals. > > But if you want to use a function from a particular project, it's more safe to > use version numbers: > ad 1) Future versions will probably still have the funtion. > ad 2) Older versions don't have it. > ad 3) If another project provides the same functionality, your build scripts > wouldn't be able to use it. I strongly disagree on this - All "version" checks are unreliable and should remain the absolute last resort if all else fail. Rationale: "version checks" can only work if all existing shipped binaries of a package provide identical functionality, i.e. if a package doesn't have optional features nor has patches applied. This almost never is the case in any OpenSource project. Example: KDE's gcc-4.0.0 blacklisting. KDE tripped a bug in gcc-4.0.0 which affects a lot of KDE stuff, so they wanted to be clever and blacklisting gcc-4.0.0. They missed that almost all vendor-supplied gccs are patched, so whatever version number a particular gcc might return on a system, has no actual connection to whether this gcc is affected by the bug KDE found worth blacklisting gcc for or not. Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
