[MetaCRS] Motion: Adopt libgeotiff 1.4.1RC2 as 1.4.1 Release

[Howard Butler]

On Sep 18, 2014, at 9:30 AM, Charles Karney <charles.karney at sri.com> wrote:

> On 2014-09-18 10:10, Howard Butler wrote:
>> 
>> On Sep 17, 2014, at 10:36 AM, Charles Karney <charles.karney at sri.com> wrote:
>> 
>>> On 2014-09-17 02:51, Frank Warmerdam wrote:
>>>> Folks,
>>>> 
>>>> I have prepare a release candidate for libgeotiff which I believe is
>>>> ready to adopt as a formal release.  This is an official motion to the
>>>> MetaCRS PSC to adopt this RC as a final release.
>>>> 
>>>> Motion: Adopt libgeotiff 1.4.1RC2 as 1.4.1 Release
>>>> 
>>>> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC2.tar.gz
>>>> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC2.zip
>>>> 
>>>> This release includes a variety of fixes (described in the ChangeLog) as
>>>> well as
>>>> an upgrade to EPSG 8.5 csv files, and "in code" support for the csv
>>>> files (cmake
>>>> builds only).
>>> 
>>> Under Linux, the shared library has the same version number as 1.4.0,
>>> libgeotiff.so.2.1.0.  Is this OK?  (This is with a cmake build.)
>> 
>> I think this is incorrect. For the CMake build, like the autotools one, I think the so name should be so.3.1.1  We should probably issue a new RC to clean this up.
>> 
> 
> Maybe you meant 2.1.1 (the number assigned by autoconf?)

I have pushed changes to this effect in SVN. Can you please pull them down and report (to me at least) their validity?

> 
>>> 
>>> Also I find it confusing that cmake says
>>> 
>>> set (GeoTIFF_VERSION_MAJOR 2)
>>> set (GeoTIFF_VERSION_MINOR 1)
>>> set (GeoTIFF_VERSION_RELEASE 0)
>> 
>> I agree this is messy.
>> 
>>> while the packages says 1.4.0.  I presume that the two versions became
>>> distinct because the so version number had to skip ahead?
>> 
>> 
>>> If possible, I recommend that libgeotiff be "branded" with a unique
>>> version number that tracks its releases, 1.4.1, in this case.  The so
>>> number should be tracked separately.
>> 
>> Yes, I think this is just incongruence with the (dominant and more-used) autotools stack.
> 
> Then the "right" solution, I believe is the assign a separate lib
> version.

Done in SVN.

> 
> Incidentally, I notice that the autoconf build doesn't work "out of
> source", i.e., with
>  mkdir BUILD
>  cd BUILD
>  ../configure
>  make
>  -->
> ../../libxtiff/xtiff.c:19:22: fatal error: cpl_serv.h: No such file or directory

Did this *ever* work? I guess I've never tried it, though I do frequently do out of source builds with cmake.

> 
> Does anyone care?  (I've switched to cmake so it doesn't really affect
> me.)
> 
>> 
>>> 
>>> Finally, I can supply a patch to get cmake to generate a "config-style"
>>> find package script.  I'll need a couple of days to do this (and I would
>>> need to know which the version number find_package should use).  It's
>>> fine if this doesn't make it in in time for the 1.4.1 release.
>> 
>> I'd be happy to incorporate that. I presume it'll be awhile before there's another geotiff release though.
>> 
> 
> If you can wait until early next week, I can patch the cmake
> configuration to
> 
> (1) Assign separate geotiff (1.4.1) and library (2.1.1) versions
> (2) Put the configured geo_config.h in the build tree (not the source
> tree)
> (3) Create and install find_package support

I'd like to wait for this patch to make it in. It is useful and geotiff's release schedule is so long that it will likely be more than a year before it would make it out to packagers. Another week isn't too bad. Does that sound ok Frank/others?