You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please consider versioning the project as a whole and tagging releases. This would make things much easier for anyone packaging and redistributing animx. (I want to add an animx package to Fedora Linux.)
Similarly, it would be really helpful if shared library versioning could be added. CMake makes this pretty easy. Typically, especially for projects with C APIs/ABIs, the ABI version is a single integer that starts at 1 and is incremented each time a backwards-incompatible ABI change is made (like removing a function, or changing the type of one of its arguments). The value is encoded in the SONAME field of the shared library file using a linker flag, e.g. N=1; gcc $CFLAGS -Wl,-soname,libfoo.so.$N -o libfoo.so.$N. Then an unversioned symbolic link would be created that points at the versioned shared library. Again, CMake can handle all of this. Some projects with C++ APIs/ABIs use dotted SONAME versions, e.g. library version 1.2.3 has SONAME version 1.2 if ABI stability is guaranteed in patch releases. Others can’t guarantee any ABI stability at all, and use the entire version number as the SONAME version. This is still useful, as long as it reflects reality.
All of this is important for packaging animx in Linux distributions. In the case of Fedora, we can add the SONAME version downstream if necessary, but one managed upstream is much better, as it benefits everyone and ensures consistency across distributions.
The text was updated successfully, but these errors were encountered:
Please consider versioning the project as a whole and tagging releases. This would make things much easier for anyone packaging and redistributing animx. (I want to add an
animx
package to Fedora Linux.)Similarly, it would be really helpful if shared library versioning could be added. CMake makes this pretty easy. Typically, especially for projects with C APIs/ABIs, the ABI version is a single integer that starts at
1
and is incremented each time a backwards-incompatible ABI change is made (like removing a function, or changing the type of one of its arguments). The value is encoded in theSONAME
field of the shared library file using a linker flag, e.g.N=1; gcc $CFLAGS -Wl,-soname,libfoo.so.$N -o libfoo.so.$N
. Then an unversioned symbolic link would be created that points at the versioned shared library. Again, CMake can handle all of this. Some projects with C++ APIs/ABIs use dottedSONAME
versions, e.g. library version1.2.3
hasSONAME
version 1.2 if ABI stability is guaranteed in patch releases. Others can’t guarantee any ABI stability at all, and use the entire version number as theSONAME
version. This is still useful, as long as it reflects reality.All of this is important for packaging animx in Linux distributions. In the case of Fedora, we can add the
SONAME
version downstream if necessary, but one managed upstream is much better, as it benefits everyone and ensures consistency across distributions.The text was updated successfully, but these errors were encountered: