Le 17/02/2022 à 10:35, Kristian Evers via PROJ a écrit :
Thanks for the thorough explanation, Bas. It's much appreciated!
Even, Mike: I haven't got strong opinions on this. Do you guys think it is
worth the hassle to switch to the model Bas describes here?
I also don't have a strong opinion. One advantage is that it makes it
more obvious which PROJ version the lib is. The only potential issue I
can imagine is that if some day we have a PROJ 22.2.1 version installed
together with PROJ 8.2.1, they would both be libproj.so.22.2.1, but
that's probably mostly a theoretical concern...
/Kristian
-----Original Message-----
From: PROJ <[email protected]> On Behalf Of Sebastiaan
Couwenberg
Sent: 16. februar 2022 12:38
To: [email protected]
Subject: Re: [PROJ] PROJ 9.0.0RC1 & PROJ-data 1.9RC1
On 2/16/22 09:35, Kristian Evers via PROJ wrote:
Bas, I'm not sure how to understand this.
So you go from (8.2.1):
/usr/lib/x86_64-linux-gnu/libproj.so -> libproj.so.22.2.1
/usr/lib/x86_64-linux-gnu/libproj.so.22 -> libproj.so.22.2.1
/usr/lib/x86_64-linux-gnu/libproj.so.22.2.1
To (9.0.0):
/usr/lib/x86_64-linux-gnu/libproj.so -> libproj.so.9.0.0
/usr/lib/x86_64-linux-gnu/libproj.so.25 -> libproj.so.9.0.0
/usr/lib/x86_64-linux-gnu/libproj.so.9.0.0
Are you suggesting that we ONLY use the major, minor and patch version
numbers for the so-files and forget about the SOVERSION from now on?
No, SOVERSION is essential as it is part of the SONAME:
<NAME>.so.<SOVERSION>
Where <NAME> = libproj, and <SOVERSION> = 25
If that is the case, personally I'm all for it since I've always found the
current/revision/age difficult (as is evident in several release candidates
in the past) but is that a common practice among project that base their
packages on CMake?
autotools determines the versions (both 22 and 22.2.1 in the above
examples for 8.2.1 with version-info 24:1:2) based on the version-info.
SOVERSION (the 22 in libproj.so.22) is determined by CURRENT minus AGE,
the filename version (22.2.1 in libproj.so.22.2.1) is determined by
(CURRENT-AGE).AGE.REVISION or some other magic.
The SOVERSION cannot be decremented and must be incremented every
release that breaks the ABI. This was 22 in 8.2.1, is currently 25 in
9.0.0-rc1, and could also be 23 in 9.0.0-rc2.
You configure this in CMake with:
set_target_properties(proj
PROPERTIES
VERSION <X>.<Y>.<Z>
SOVERSION <N>
)
This creates the files:
libproj.so (symlink to libproj.so.<X>.<Y>.<Z>)
libproj.so.<N> (symlink to libproj.so.<X>.<Y>.<Z>)
libproj.so.<X>.<Y>.<Z>
Now that autotools and libtool are no longer used, you don't have to use
the complicated logic to determine the VERSION value (<X>.<Y>.<Z>).
For projects that start with CMake and only support that it's common to
use the project major version for the SOVERSION value and full project
version for VERSION value.
That cannot be used for PROJ as it is migrating away from autotools and
cannot decrement the SOVERSION to 9.
This situation is similar to what MapServer did some time ago, that
currently uses:
set_target_properties(mapserver
PROPERTIES
VERSION ${MapServer_VERSION_STRING}
SOVERSION 2
)
This is what I also suggest for PROJ to make library versioning easier
now that the libtool complications are gone.
Since code speaks louder than words, see the attached patch for an
example of what I mean.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
