Fix versioning informations in shared libraries

[masterleinad]

Related to #2283.

[dalg24]

@masterleinad Please resolve conflicts.

@junghans Please review.

[junghans]

Can you rebase this on top of the merged #2288? And I will test

[junghans]

You want both SOVERSION and VERSION as apps will link against libkokkos.so.3 and not libkokkos.so.3.0.0, fix here: masterleinad#1

[masterleinad]

Fixed.

[crtrott]

Can someone explain the reasoning behind linking .so.3 instead of .so.3.0.0?
And wouldn't that indicate that we plan on ABI compatibility of our libraries? Kokkos most definitely will not provide that guarantee. I do not see a good reason to do it, and plenty for not doing it (the ABI compatibility).

[junghans]

Can someone explain the reasoning behind linking .so.3 instead of .so.3.0.0?
And wouldn't that indicate that we plan on ABI compatibility of our libraries? Kokkos most definitely will not provide that guarantee. I do not see a good reason to do it, and plenty for not doing it (the ABI compatibility).

Good question, having just .so.3.0.0 seems a bit non-standard. If you don't want to imply ABI compatibility using something like the date might be a better solution.

[masterleinad]

I have seen .so.major.minor.patch or .so.major.minor for some libraries (deal.II, PETSc) and didn't hear about complains regarding that.

[junghans]

I have seen .so.major.minor.patch or .so.major.minor for some libraries (deal.II, PETSc) and didn't hear about complains regarding that.

Ok, then let's do that. I just tested it with Cabana and Kokkos as well.

[masterleinad]

I dropped the last commit.

[crtrott]

Next thing: there is a compatibility check and it says "same major version". That is not true either. Kokkos promises backward compatibility not forward. I.e. code written against 3.1 will work with 3.2. But code written against 3.2 may not work against 3.1.

[junghans]

Are you referring to the SameMajorVersion compatibility statement?

That seems to be correct reading the CMake doc: “The COMPATIBILITY mode AnyNewerVersion means that the installed package version will be considered compatible if it is newer or exactly the same as the requested version. This mode should be used for packages which are fully backward compatible, also across major versions. If SameMajorVersion is used instead, then the behaviour differs from AnyNewerVersion in that the major version number must be the same as requested, e.g. version 2.0 will not be considered compatible if 1.0 is requested. This mode should be used for packages which guarantee backward compatibility within the same major version. If ExactVersion is used, then the package is only considered compatible if the requested version matches exactly its own version number (not considering the tweak version). For example, version 1.2.3 of a package is only considered compatible to requested version 1.2.3. This mode is for packages without compatibility guarantees. If your project has more elaborated version matching rules, you will need to write your own custom ConfigVersion.cmake file instead of using this macro.”

[crtrott]

Ah ok. That is fine then.