[Proj] 4.9.1RC1 Released

[Even Rouault]

Le samedi 21 février 2015 15:52:10, Charles Karney a écrit :
> On 02/21/2015 09:15 AM, Even Rouault wrote:
> > Le samedi 21 février 2015 14:18:22, Charles Karney a écrit :
> >> On 02/20/2015 10:48 PM, Howard Butler wrote:
> >>> As requested, I have issued one more RC, with the items from Markus,
> >>> Sebastiaan, and Charles. Please report any findings or issues as
> >>> before.
> >>> 
> >>> http://download.osgeo.org/proj/proj-4.9.1RC2.tar.gz
> >>> 
> >>> Thanks,
> >> 
> >> Please apply the following patches to proj-4.9.1RC2 (in addition to
> >> including man/CMakeLists.txt and cmake/policies.cmake as noted by Even).
> > 
> >> These patches fix:
> > Applied. I had to manually apply since the patch got somehow corrupted in
> > the email. An attachment would have been better.
> > 
> > I blindly trust you for the cmake windows part...
> > 
> > 
> > One thing I noticed is that the set of installed headers isn't the same
> > between autoconf and cmake :
> > 
> > ../../install-proj-4.9.1-cmake/include/emess.h  (should be internal only
> > no ?) ../../install-proj-4.9.1-cmake/include/proj_api.h
> > ../../install-proj-4.9.1-cmake/include/projects.h
> > ../../install-proj-4.9.1-cmake/include/pj_list.h (should be internal only
> > no ?) ../../install-proj-4.9.1-cmake/include/proj_config.h (should be
> > internal only no ?)
> > 
> > ../../install-proj-4.9.1-autoconf/include/proj_api.h
> > ../../install-proj-4.9.1-autoconf/include/org_proj4_Projections.h 
> > (missing in cmake ?)
> > ../../install-proj-4.9.1-autoconf/include/projects.h
> > ../../install-proj-4.9.1-autoconf/include/geodesic.h  (missing in cmake
> > ?) ../../install-proj-4.9.1-autoconf/include/org_proj4_PJ.h  (missing in
> > cmake ?)
> 
> Attached (!) is a patch to install the right headers (include geodesic.h
> exclude internal headers).  The org_* headers aren't installed because
> JNI support is missing from cmake.
> 
> I also added CH to be list of extra projections to be installed.

Applied

> 
> One serious discrepancy is that the numbering of the so libraries.
> These are different between cmake and autoconf (and the cmake libraries
> have two sets of numbers!?).  I'm not sure how best to handle this...
> 

Me neither. For folks looking, here's the state of things :

$ find ../install-proj-4.9.1-autoconf/lib/
../install-proj-4.9.1-autoconf/lib/
../install-proj-4.9.1-autoconf/lib/libproj.so.9
../install-proj-4.9.1-autoconf/lib/libproj.a
../install-proj-4.9.1-autoconf/lib/pkgconfig
../install-proj-4.9.1-autoconf/lib/pkgconfig/proj.pc
../install-proj-4.9.1-autoconf/lib/libproj.la
../install-proj-4.9.1-autoconf/lib/libproj.so
../install-proj-4.9.1-autoconf/lib/libproj.so.9.0.0

$ find ../install-proj-4.9.1-cmake/lib/
../install-proj-4.9.1-cmake/lib/
../install-proj-4.9.1-cmake/lib/libproj.so.4.9.1
../install-proj-4.9.1-cmake/lib/libproj.so
../install-proj-4.9.1-cmake/lib/libproj.so.9.0.0

And for reference:
$ find ../install-proj-4.8.0/lib  (autoconf build)
../install-proj-4.8.0/lib
../install-proj-4.8.0/lib/libproj.a
../install-proj-4.8.0/lib/libproj.so.0.7.0
../install-proj-4.8.0/lib/pkgconfig
../install-proj-4.8.0/lib/pkgconfig/proj.pc
../install-proj-4.8.0/lib/libproj.la
../install-proj-4.8.0/lib/libproj.so
../install-proj-4.8.0/lib/libproj.so.0

> Another less serious issue is that proj_api.h defines
> 
>    #define PJ_VERSION 491
> 
> What's going to happen with 4.10.0?  (I assume we won't want to go to
> 5.0?)
> I suggestion leaving this definition (for now at any rate), but
> adding
> 
>    #define PROJ_VERSION_MAJOR 4
>    #define PROJ_VERSION_MINOR 9
>    #define PROJ_VERSION_PATCH 1
> 
>    #define PROJ_VERSION_NUM(a,b,c) ((((a) * 10000 + (b)) * 100) + (c))
> 
>    #define PROJ_VERSION \
>      PROJ_VERSION_NUM(PROJ_VERSION_MAJOR, PROJ_VERSION_MINOR,
> PROJ_VERSION_PATCH)

Yes, that could do it. We did a similar trick when releasing GDAL 1.10. The 
new numbering rule is still compatible with the older one (that is: newer 
versions have PROJ_VERSION greater than the one of previous versions).

> 
> Two other fixes to proj4 are on my list:
> 
> (A) Fix the runtime library path for the executables with the cmake
> install.
> 
> (B) Install cmake config support for proj (so that other cmake projects
> can find it with find_package(PROJ).  On this point:
> 
>    (1) I plan to use PROJ4 as the package name (case is significant
>    here).  Any objections?  Alternatives Proj4, proj4.  Possibly the "4"
>    should be left off and the user expected to do
> 
>      find_package (PROJ 4)
> 
>    I don't feel very strongly about this.  However, it will be important
>    to stick with a single convention.

The pkgconfig name is proj. That let the door opened for proj 5

> 
>    (2) There's already a file in the distribution called
> 
>      cmake/Proj4Config.cmake
> 
>    This name is probably a bad idea since it will be matched by the
>    find_package file lookup.  How about if I rename it to
>    Proj4Configuration.cmake

Sounds reasonable to me.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com