Le jeudi 08 novembre 2012 23:09:16, Frank Warmerdam a écrit : > On 12-11-08 01:49 PM, Even Rouault wrote: > >> I appologise to Howard or others who have been tuning configuration > >> logic for a 2.0 release. > > > > It depends on how they have tuned... > > > > We have a small technical detail to solve with 1.10 because of > > # define GDAL_VERSION_NUM > > (GDAL_VERSION_MAJOR*1000+GDAL_VERSION_MINOR*100+GDAL_VERSION_REV*10+GDAL_ > > VERSION_BUILD) > > > > With the current definition 1.10 and 2.0 would resolve to 2000... > > Annoying. > > > > So we would need to redefine it likely as > > > > # define GDAL_VERSION_NUM > > (GDAL_VERSION_MAJOR*1000000+GDAL_VERSION_MINOR*10000+GDAL_VERSION_REV*100 > > +GDAL_VERSION_BUILD) > > > > and 1.10 would then be 1100000 which is still greater than 2000 ... > > Even, > > Ugg. OK, I now remember this being one of the reasons I'm not in > favor of a 1.10 release. I'm not too fond of redefining GDAL_VERSION_NUM's > layout. I wonder if this would cause any surprising problems.
I can't imagine any particular problem this would cause. I've tried to think at crazy stuff, like dividing GDAL_VERSION_NUM by 100.0, and do for example #if GDAL_VERSION_NUM / 100.0 >= 1.8 But floating point in preprocessing is not allowed, and even if they did that, this would still work with the new way of computation GDAL_VERSION_NUM. The only constraint I see is that the version numbers for the next versions are greater than the ones of previous releases. I've checked in QGIS and MapServer, and they both do stuff like : #if defined(GDAL_VERSION_NUM) && GDAL_VERSION_NUM >= 1600 > > Blech _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
