Add soname/soversion in Unix libs

[sl1pkn07]

https://en.wikipedia.org/wiki/Soname
https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html

Also add PROJECT_VERSION in the project() function with moving some code from avs_core\CMakeLists.txt to main CMakeLists

the SONAME/SOVERSION "rename" the libarary to libavistnth.so.X.X.X and add symlink to libavisynth.so.X and libavisynth.so

└───╼  ls libavisynth.so*
lrwxrwxrwx 1 sl1pkn07 users       16 mar 19 02:00 libavisynth.so -> libavisynth.so.3
lrwxrwxrwx 1 sl1pkn07 users       20 mar 19 02:00 libavisynth.so.3 -> libavisynth.so.3.5.0
-rwxr-xr-x 1 sl1pkn07 users 10916424 mar 19 02:00 libavisynth.so.3.5.0
└───╼  objdump -p libavisynth.so.3.5.0 | grep SONAME
  SONAME               libavisynth.so.3
└───╼  readelf -d libavisynth.so.3.5.0 | grep SONAME
 0x000000000000000e (SONAME)             Nombre-so de la biblioteca: [libavisynth.so.3]

[qyot27]

I'm not opposed on principle, but I should note that AviSynth (Classic or Plus) major.minor.bugfix version numbers have little/no bearing on API or ABI compatibility. Anyone trying to use a soversion based on the release versioning to determine those things is potentially going to get burned at some point. Or at least express real confusion about lib compatibility when the numbers bump but there's not really any difference to end programs.

What does make some sense to use is the value of AVISYNTH_INTERFACE_VERSION, as that is supposed to directly map to API breaks or changes. I just bumped it in 40900dc, which, while it may seem arbitrary at this point, had actually been necessary for a while (high bit depth support added a set of new functions which we otherwise had to use GetProcAddress to detect instead of it being determined by the value returned by avs_get_version). Also, because Classic has been inactive for nearly four years, the path for us to do so is more or less clear.

[sl1pkn07]

then you mean, use in SOVERSION, the value of AVISYNTH_INTERFACE_VERSION?

[qyot27]

Yes, so the result would be libavisynth.so.7.0.0 in this case (or omit the extra zeroes, if there's no strict requirement for them to be there).

[sl1pkn07]

let me try it

[sl1pkn07]

like this?

└───╼  ls *.so*
lrwxrwxrwx 1 sl1pkn07 users       16 mar 19 20:17 libavisynth.so -> libavisynth.so.7
-rwxr-xr-x 1 sl1pkn07 users 10916424 mar 19 20:17 libavisynth.so.3.5.0
lrwxrwxrwx 1 sl1pkn07 users       20 mar 19 20:17 libavisynth.so.7 -> libavisynth.so.3.5.0
└───╼  objdump -p libavisynth.so.3.5.0 | grep SONAME
  SONAME               libavisynth.so.7

[qyot27]

After reading more about how all this is supposed to work together, a few things:

A) The plugins do not need the SOVERSION appended to them. From Fedora's packaging guidelines:

As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries. These files are usually plugins or modular functionality specific to an application, and are not located in the ld library paths or cache. This means that they are not located directly in /usr/lib or /usr/lib64, or in a directory listed as a library path in /etc/ld.so.conf (or an /etc/ld.so.conf.d/config file). Usually, these unversioned shared objects can be found in a dedicated subdirectory under /usr/lib or /usr/lib64 (e.g. /usr/lib/purple-2/ is the plugin directory used for libpurple applications).

That's exactly the case here. None of the plugins in AviSynth+'s source tree are installed as system libraries. Not to mention that three of them will never be built or run on non-Windows OSes, making adding that information for them completely unnecessary.

B) Despite trying to look for it, I couldn't find anything in the CMake documentation or Google stating that a PROJECT_VERSION was required, or what it would be required for. In fact, what was stated was that in a case where either PROJECT_VERSION or SOVERSION was missing, the value of the one that does exist would be assumed to be the value of the other.

A and B together basically mean that there's no reason to change away from AVS_VERSION or to put it in the top-level CMakeLists.txt, because the only thing using it is the core library itself, and CMake can use the SOVERSION without a PROJECT_VERSION being set. The plugins' CMakeLists also don't need to be changed due to not being system libraries.

C) The real intention of three numbers appended to the SONAME to act as versioning is significantly trickier to tease out when talking about AviSynth+, because AVISYNTH_INTERFACE_VERSION covers the descriptions of both the current and revision numbers. Even then, not all libraries on Linux contain 3, or even 2 fields for this (and the third number may not be used at all on other *nix systems). Many of them seem to only make use of the current number.

And when thinking through exactly what this means for us, there's three options: use only the current number, set to AVISYNTH_INTERFACE_VERSION, and leave it at that (libavisynth.so.7 and a libavisynth.so symlink to it), or like you've done here, have the release number in the fully-versioned soversion and then a symlink using the interface version and a symlink to the plain soname (libavisynth.so.3.5.0, and libavisynth.so.7 and libavisynth.so as symlinks to it). The first option may run afoul of any actual requirement to use a x.x(.x) SOVERSION, if any distro does get that specific about it, and the second doesn't really address the fact that '3.5.0' means nothing in regard to API or ABI compatibility, even if it does satisfy the stipulation that multiple versions of libavisynth could be installed at the same time. At least option one tied it absolutely to the interface version.

Which leaves option three: include the release number in the SONAME, and use the interface version in the SOVERSION, so that you'd have libavisynth-3.5.0.so.7 as the filename of the real library and two symlinks: libavisynth-3.5.0.so and libavisynth.so (which has to be created using a custom target). Like I've done in this commit on my repo (which is the bare minimum the topic requires; cleanups of CMake's logging messages during configuration need to be in separate commits anyway). The results:

[AviSynthPlus:$] ls -l /usr/local/lib/libavisynth*
lrwxrwxrwx 1 root root       22 Mar 19 22:37 /usr/local/lib/libavisynth-3.5.0.so -> libavisynth-3.5.0.so.7
-rw-r--r-- 1 root root 11148544 Mar 19 22:41 /usr/local/lib/libavisynth-3.5.0.so.7
lrwxrwxrwx 1 root root       22 Mar 19 22:42 /usr/local/lib/libavisynth.so -> libavisynth-3.5.0.so.7
[AviSynthPlus:$] objdump -p /usr/local/lib/libavisynth-3.5.0.so.7 | grep SONAME
  SONAME               libavisynth-3.5.0.so.7

[sl1pkn07]

Hi

mmm, i'm not touch nothing abot the SONAME in plugins. the soname/version should be untouched in that libraries

about PROJECT_VERSION https://cmake.org/cmake/help/latest/command/project.html, the info is not clear, but all cmake project i see have VERSION set in project(), and PROJECT_VERSION is autogenerated thing when VERSION in project() is set https://cmake.org/cmake/help/latest/variable/PROJECT_VERSION.html#variable:PROJECT_VERSION

the '3.5.0' for me is only for informative thing. but if you see in your local /usr/lib, the immensely majority of the library have this scheme, and is not thing of cmake purely. autotools, meson, and other generated configfiles (if the dev desire), is set byself when build any library (other libraryes have generated as 1.0.0 and not is necessary points to the version of the project)

if you prefeer use other file naming scheme, i'm not problem with it. but i prefeer flollow the mainstream

EDIT: the disscusion about how cmake handle PROJECT_VERSION you can see a example in here apache/mxnet#17815. is the same thing and the same way i whant implement here (in the resolved changes ahave examples when works or not)

[qyot27]

Due to weirdness in testing (read: ldconfig wiping the install directory if a suffixed SONAME and non-suffixed symlink exists, requiring client programs to set LD_LIBRARY_PATH to find AviSynth+), I simply decided to go with the middle option, libavisynth.so.3.5.0, and symlinks to libavisynth.so.7 and libavisynth.so. It'll look weird, but it's the closest we can come to what people traditionally expect SOVERSIONs to actually indicate.

I did take the liberty to break the commit up into its constituent topics, though. It's present in git master as well as the 3.5.1 tarball.