Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: enable use of versioned SONAME #2

Merged
merged 1 commit into from May 29, 2015

Conversation

Projects
None yet
2 participants
@vincentbernat
Copy link
Contributor

vincentbernat commented May 27, 2015

Most libraries are using a versioned SONAME to track API changes. When
they don't, we usually use a SOVERSION of 0. When willing to commit to
some API stability, SOVERSION and VERSION should be updated to more
adequate values (VERSION could match the library version, assuming it
follows the major.minor.patch convention and SOVERSION could be
major.minor since CMake doesn't support libtool versioning scheme with
age).

With this change CMake will install the library as
libcbor.so.0.0.0. libcbor.so.0 will be a symlink to the library for
other applications, to be found with the dynamic linker. libcbor.so will
be a symlink to libcbor.so.0 for use by the linker (ld).

build: enable use of versioned SONAME
Most libraries are using a versioned SONAME to track API changes. When
they don't, we usually use a SOVERSION of 0. When willing to commit to
some API stability, SOVERSION and VERSION should be updated to more
adequate values (VERSION could match the library version, assuming it
follows the major.minor.patch convention and SOVERSION could be
major.minor since CMake doesn't support libtool versioning scheme with
age).

With this change CMake will install the library as
libcbor.so.0.0.0. libcbor.so.0 will be a symlink to the library for
other applications, to be found with the dynamic linker. libcbor.so will
be a symlink to libcbor.so.0 for use by the linker (ld).
@vincentbernat

This comment has been minimized.

Copy link
Contributor Author

vincentbernat commented May 28, 2015

For SOVERSION, since CMake doesn't allow to use libtool convention, some big projects just use a single integer they increment each time the API changes. This number is not correlated to the version number. This would be something like that (I just use a big number to show the concept):

# Increment each time the public API is changed
set(CBOR_API_VERSION 17)
set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor SOVERSION ${CBOR_API_VERSION})
if(WINDOWS)
  set_target_properties(cbor_shared PROPERTIES VERSION ${CBOR_VERSION})
endif()

The other way is to have something like this:

set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor 
     SOVERSION ${CBOR_VERSION_MAJOR}.${CBOR_VERSION_MINOR}
     VERSION ${CBOR_VERSION})
@PJK

This comment has been minimized.

Copy link
Owner

PJK commented May 29, 2015

Thanks, @vincentbernat, I learned something new today :)

This looks good enough to start with. I'm only vaguely familiar with libtool's conventions and I haven't really taken it into account since I find it quite difficult to work with when using build system other than autotools (correct me if I'm wrong).

Is there any significant drawback to using the

set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor 
     SOVERSION ${CBOR_VERSION_MAJOR}.${CBOR_VERSION_MINOR}
     VERSION ${CBOR_VERSION})

approach? It seems like it would fit in nicely with semver

PJK added a commit that referenced this pull request May 29, 2015

Merge pull request #2 from vincentbernat/fix/soversion
build: enable use of versioned SONAME

@PJK PJK merged commit 16bb6d0 into PJK:master May 29, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

PJK added a commit that referenced this pull request May 29, 2015

@vincentbernat

This comment has been minimized.

Copy link
Contributor Author

vincentbernat commented May 29, 2015

As long as you think to at least increase the minor version when changing API, I think this is fine.

PJK added a commit that referenced this pull request May 30, 2015

PJK added a commit that referenced this pull request May 30, 2015

Improve fuzz testing with a fake malloc and CI compat
Debugging CI

Debugging CI #2

Debugging CI #3

Debugging CI #4

Debugging CI #5

Debugging CI #6

PJK added a commit that referenced this pull request Jan 6, 2017

PJK added a commit that referenced this pull request Jan 10, 2017

PJK added a commit that referenced this pull request Jan 11, 2017

PJK added a commit that referenced this pull request Sep 30, 2017

PJK added a commit that referenced this pull request Feb 2, 2019

PJK added a commit that referenced this pull request Feb 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.