[MacPorts] #55583: snappy @1.1.7: restore shared library build (and use the up-to-date cmake PG)

[MacPorts]

#55583: snappy @1.1.7: restore shared library build (and use the up-to-date cmake
PG)
---------------------+----------------------
  Reporter:  RJVB    |      Owner:
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  haspatch
      Port:  snappy  |
---------------------+----------------------

Comment (by RJVB):

 I've attached a patch that adds a no-frills solution to build both shared
 and static libraries. It could probably be done a bit more elegantly but
 given how small the project is there's hardly a penalty to building
 everything twice.

 Changing the compatibility version back to 5.0.0 is a different matter.
 I've not found a good way to do this, because cmake imposes the SOVERSION
 as the compatibility version. So either we get `libsnappy.dylib ->
 libsnappy.1.dylib -> libsnappy.1.1.7.dylib` with compat. version 1.0.0, or
 we get `libsnappy.dylib -> libsnappy.5.dylib -> libsnappy.1.1.7.dylib` .
 The only way to restore the 5.0.0 compat. version would thus be to set the
 SOVERSION to 5 in the CMake file, and then to rename libsnappy.5.dylib
 (and update the link library symlink).

 FWIW, the "5" number probably comes from the strange way libtool encodes
 library versions (see https://cmake.org/Bug/view.php?id=4383#c6870 and
 beyond; I'm guessing the previous snappy build system used libtools
 `-version-info 5:x:y) IOW, this is indeed an unhappy side-effect that
 bites on OS X only, not on Linux where only the filename counts (which
 hasn't changed).

--
Ticket URL: <https://trac.macports.org/ticket/55583#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS