The only reservation I have is that new APIs can get introduced in minor
releases as well as major releases. As such, wouldn't it be better if "5.0"
were used? A library for a 5.1 release might contain APIs that a 5.0
release does not. The old convention was probably an error.
Note that "new APIs" in this sense only applies to new entry points added
to the libraries. APIs added to the context vectors are a different
mechanism and shouldn't cause problems.
Rick
On Sun, Jul 26, 2020 at 7:50 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> On 25.07.2020 20:10, Rony G. Flatscher wrote:
>
> On 25.07.2020 18:57, Rony G. Flatscher wrote:
>
> The library names of the Unix (Linux and Mac) versions of ooRexx added
> links to support earlier ooRexx versions in the form
>
> - Linux
> - "lib" name ".so.${ORX_MAJOR}", e.g.
> - librexx.so -> librexx.so.3
> librexx.so -> librexx.so.4
> ....
> - librexxapi.so -> librexxapi.so.3
> librexxapi.so -> librexxapi.so.4
> ...
>
> - MacOS
> - "lib" name ".${ORX_MAJOR}.dylib", e.g.
> - librexx.dylib -> librexx.3.dylib
> librexx.dylib -> librexx.4.dylib
> ...
> - librexxapi.dylib -> librexxapi.3.dylib
> librexxapi.dylib -> librexxapi.4.dylib
> ...
>
> The version number in the current ooRexx 5.0 beta on Unix (Linux, MacOS)
> use in addition to ${ORX_MAJOR} the subnumbers ${ORX_MINOR}.${ORX_MOD_LVL,
> thereby unnecessarily breaking the naming system, e.g.:
>
> - Linux
> - "lib" name ".so.${ORX_MAJOR}", e.g.
> - librexx.so -> librexx.so.3
> librexx.so -> librexx.so.4
> librexx.so -> librexx.so.5.0.0
> ....
> - librexxapi.so -> librexxapi.so.3
> librexxapi.so -> librexxapi.so.4
> librexxapi.so -> librexxapi.so.5.0.0
> ...
>
> - MacOS
> - "lib" name ".${ORX_MAJOR}.dylib", e.g.
> - librexx.dylib -> librexx.3.dylib
> librexx.dylib -> librexx.4.dylib
> librexx.dylib -> librexx.5.0.0.dylib
> ...
> - librexxapi.dylib -> librexxapi.3.dylib
> librexxapi.dylib -> librexxapi.4.dylib
> librexxapi.dylib -> librexxapi.5.0.0.dylib
> ...
>
> Suggesting to changing the versioned library names of ooRexx 5 to match
> the established convention (using only ${ORX_MAJOR}).
>
> Are there any objections to such a change?
>
> ---
>
> If not, where does "CMAKE_SHARED_LIBRARY_PREFIX" get set (which gets used
> for setting "ORX_SHARED_LIBRARY_EXT")?
>
> It seems that the above two variables play no role in the version string
> for the link file names. Rather the usage of "set_target_properties(libname
> PROPERTIES VERSION ${ORX_VERSION})" for each "libname" defines the version
> string to use [1]. So probably using "${ORX_MAJOR}" instead of
> "${ORX_VERSION}" would make the version string in the link names to consist
> of "5" only.
>
> ---rony
>
> [1] Search for "VERSION" in:
> <https://cmake.org/cmake/help/v3.0/command/set_target_properties.html>
> <https://cmake.org/cmake/help/v3.0/command/set_target_properties.html> to
> yield:
>
> "... For shared libraries VERSION and SOVERSION can be used to specify the
> build version and API version respectively. When building or installing
> appropriate symlinks are created if the platform supports symlinks and the
> linker supports so-names. If only one of both is specified the missing is
> assumed to have the same version number. For executables VERSION can be
> used to specify the build version. When building or installing appropriate
> symlinks are created if the platform supports symlinks. For shared
> libraries and executables on Windows the VERSION attribute is parsed to
> extract a “major.minor” version number. These numbers are used as the image
> version of the binary. ...".
>
> What the enclosed patch does to "CMakeLists.txt" (tested on Ubuntu):
>
> - changes the variable name in "set_target_properties" for library
> version from "VERSION" to "SOVERSION", which will self-document the purpose
> of that property (cf. [1] above),
> - changes the value from "${ORX_VERSION}" (i.e. "5.0.0") to
> "${ORX_MAJOR}" (i.e. "5")
>
> If there are no objections I will check-in that patch.
>
> ---rony
>
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
