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

[Charles Karney]

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?)

>>
>> 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.

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

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