Normalize libgeos.so versioning between autotools and cmake

[rmattes]

Is there any way the versioning of the libgeos library can be set to:

1) Set the SOVERSION to majorversion.minorversion instead of majorversion.minorversion.patchversion? ​http://upstream-tracker.org/versions/libgeos.html indicates that this is sufficient to guard against ABI breakages

2) Remove the version from the name of the library, and append it after the file extension instead (e.g. instead of libgeos-3.3.8.so, provide libgeos.so.3.3.8 like autotools is doing now?)

For CMake, you can create an SOVERSION variable as "MAJOR.MINOR", and setting the SONAME target property in src/CMakeLists.txt to your SOVERSION.

The autotools scripts are using the -release linker flag, which is putting the version name in the library directly. Using -version-info instead, like the C API is, should have the same effect (though I'm not as much of an autotools expert.)

[rmattes]

Sorry, the CMake property is called SOVERSION, not SONAME

[strk]

libgeos.so versioning is intentionally breaking on every release. libgeos_c.so versioning is the one with a stable SONAME.

[rmattes]

According to ​http://upstream-tracker.org/versions/libgeos.html, the ABI is not breaking with every release, just when the minor version gets bumped. Why do you need to intentionally break it?

That said, CMake and Autotools are still producing libraries with different names: cmake produces libgeos.so.x.y.z, and autotools produces libgeos-x.y.z.so. The SONAMEs within the library are also different depending on whether CMake or Autotools is used.

[strk]

Is the software running on upstream-tracker.org really able to compare ABI when it comes to changing order of public methods or adding/dropping const qualifiers or worst ownership semantic ? We're keeping the door open to do those things, particularely const qualifiers and pointers-to-references or back.

CMake using a different SONAME should probably be discussed in #446, reopening it if needed. Adding Mateusz in Cc here

[robe]

Milestone renamed

[darkblueb]

comparison of installed libGEOS from master branch, under debian/Ubuntu, autotools first, then cmake second. Note multiple issues with the generated files. (see screenshots)

[pramsey]

-rwxr-xr-x  1 pramsey  staff  14684152 25 Sep 11:12 libgeos.3.8.0.dylib
-rwxr-xr-x  1 pramsey  staff    778320 25 Sep 11:15 libgeos_c.1.12.0.dylib
lrwxr-xr-x  1 pramsey  staff        22 25 Sep 11:15 libgeos_c.1.dylib -> libgeos_c.1.12.0.dylib
lrwxr-xr-x  1 pramsey  staff        17 25 Sep 11:15 libgeos_c.dylib -> libgeos_c.1.dylib

So, I have a patch almost ready which just tries to ape autotools, which basically enforces our longstanding Policy that the libgeos ABI can break at any time, so people have to rebuild on every patch release (pretty harsh, but I think we have in fact had ABI breakages on patch, because fixes have done things like add extra classes and the symbol tables have ended up slightly different) while the CAPI provides as stable an endpoint as possible and hence symlinks. The above are the libraries, as installed by cmake, on OSX (hence the dylib suffixing).

[pramsey]

Closed at f453c48a..a71e095d