Missing versioned symlinks for libglbinding DSO
Closed this issue · 7 comments
Currently glbinding generates a DSO without versioning information. This practice deviates from conventional shared library management on Linux.
Please consider adding the appropriate versioning infomation to the target properties of the DSO. VERSION would most likely be the fully qualified version of glbinding, whilst SOVERSION could be MAJOR if you're doing semantic versioning, 0 if you guys are not committed to a stable API yet, or something else for a custom versioning scheme. Once VERSION and SOVERSION are set, CMake should produce the versioned symlinks automatically.
Thanks,
I would agree that we should add a VERSION property containing the META_VERSION from the main cmake file. However, cmake states that Windows expects a version with a major.minor format and we use semantic versioning down to patch level. We need to check if this breaks on windows.
The SOVERSION seems to be always the major version of a project.
A quick look into my /usr/lib directory shows that they use a library containing full major.minor.patch suffix and a symlink with only the major version suffix. Libraries using this scheme doesn't provide a symlink without version suffix. How is a cmake find/configure script supposed to find the according library? Is this encoded into the cmake script?
cmake states that Windows expects a version with a major.minor format and we use semantic versioning down to patch level.
Reference please?
The SOVERSION seems to be always the major version of a project.
Depends on your versioning scheme. The only rule is to increase it when the API is changed in a backward incompatible way.
If you guys strictly follow semver, then indeed it should be the major version. 0 is the standard value for "we don't track the stability of our API yet" which happens a lot in scientific code. Feel free to adapt this value accordingly.
A quick look into my /usr/lib directory shows that they use a library containing full major.minor.patch suffix and a symlink with only the major version suffix.
See the Debian Policy Manual, sections 8.1 and 8.4.
CMake creates all the necessary symlinks anyway once the VERSION and SOVERSION target_properties are appropriately set.
Sorry I missed the source for the windows behavior.
Here it is: https://cmake.org/cmake/help/v3.0/prop_tgt/SOVERSION.html
Even if it differs from current CMake behavior, we should keep CMake 3.0 compatability for now.
Thanks for the additional documents, we will have a look at it.
All CMake is saying is that you can put whatever version string you like in the VERSION property, but on Windows only the first 2 numbers (MAJOR.MINOR) will be parsed to create the VERSIONINFO metadata which are specific to Windows DLL management.
There is no "CMake compatibility" involved in this.
Could you guys confirm at least whether the API follows semver strictly, i.e. SOVERSION should be 2, or the API is not mature yet, i.e. SOVERSION should be 0. This is important for the naming of the official Debian packages.
Thanks.
Our API versioning is stable, so 2 is correct.