Cmake improvements by BtbN · Pull Request #91 · AcademySoftwareFoundation/openapv

BtbN · 2025-05-09T17:49:46Z

These are some things I ran across while adding support to my FFmpeg builds.
Almost all of these clean up/enhance the CMake build system, the last commit puts the visibility/export macro in the right place, to make it actually work and fix the corresponding warning:

[ 86%] Building C object src/CMakeFiles/oapv_dynamic.dir/avx/oapv_tq_avx.c.o
In file included from /home/btbn/Projects/openapv/src/./oapv_def.h:43,
from /home/btbn/Projects/openapv/src/avx/oapv_tq_avx.c:32:
/home/btbn/Projects/openapv/src/../inc/oapv.h:661:1: warning: ‘visibility’ attribute ignored on non-class types [-Wattributes]
661 | char * OAPV_EXPORT oapv_version();
| ^~~~

jamrial · 2025-05-09T20:36:59Z

Project version and library/soname version don't necessarily have to match. The latter is only bumped when you want to tag a new release and is mostly cosmetic, but the latter needs to be bumped every time the API/ABI changes (Major for non-backwards compatible changes/removals, minor for backwards compatible additions).

BtbN · 2025-05-10T11:21:07Z

It's still odd and rather unusual to see the library names be "lib.so", "lib.so.0.1" and "lib.so.1". I don't think I've ever seen that.
I also don't think it's technically an issue, since I'm not aware of anything ever using the .0.1 one. So it is purely cosmetic.

jamrial · 2025-05-10T12:11:52Z

It's still odd and rather unusual to see the library names be "lib.so", "lib.so.0.1" and "lib.so.1". I don't think I've ever seen that. I also don't think it's technically an issue, since I'm not aware of anything ever using the .0.1 one. So it is purely cosmetic.

Yes, that's wrong and needs to be fixed. I was just commenting Re #86 since this PR was linked there.

BtbN · 2025-05-10T12:13:05Z

Oh, that's not something addressed here.
I can look into it though.

BtbN · 2025-05-10T17:58:51Z

Added such a header now. This should fullfill what you're looking for?

jamrial · 2025-05-10T18:42:48Z

As is, PROJECT_VERSION_MAJOR is 0 but the library soname major is 1, if I'm not mistaken.
The header defines should reflect the library soname versions, so i think there should be a separation between ABI and project versioning.

But yes, this is in the right direction. Thanks.

BtbN · 2025-05-10T18:44:14Z

Right now the soversion is just 1, while the project major is 0. While unusual, it doesn't immediately strike me as a problem.

jamrial · 2025-05-10T18:51:46Z

Project major being 0 is fine, but the public define in the header reflecting the project major and not the soname major is a problem. Library users care about API availability, and they check the public header for it. This PR right now emits

#define OAPV_VERSION_MAJOR 0
#define OAPV_VERSION_MINOR 1
#define OAPV_VERSION_PATCH 13

As in, no library user checks for ffmpeg 7.x as it's purely a cosmetic tag for packagers and not reflected anywhere in the headers. They check for lavc 61.x

BtbN · 2025-05-10T18:54:27Z

So you want to set project major == soversion?
I'd assume that when the soname is ever bumped, the major version would be as well, or at least some other version, meaning it can be checked for.
So I don't see an issue with the two being disconnected. With the defines you check for APIs, while the soname respresents the ABI version. The later is not normally of concern at the API level.

jamrial · 2025-05-10T19:06:16Z

So you want to set project major == soversion?

No, i want the header define to reflect soname major and not project major.

The reason is, this project is clearly using the project version for tagging purposes (as seen in https://github.com/AcademySoftwareFoundation/openapv/tags), bumping them when they make a new release. API additions should be reflected in both header and soname with a minor bump when they happen, not when a release is tagged.

So I don't see an issue with the two being disconnected

Them being disconnected is fine and expected. My point is that the headers should reflect one and not the other.

jamrial · 2025-05-10T19:09:17Z

So, in short, to start, project version 0.1.13 (current), soname 1.0.0 (I think?)

On API additions, soname minor is bumped, and this is reflected in the header. Project version is unchanged until a new tag is made, where they can bump it to whatever arbitrary number they want, and this is not reflected in the header.

BtbN · 2025-05-10T23:17:40Z

The soversion comes from right here: https://github.com/AcademySoftwareFoundation/openapv/blob/main/src/CMakeLists.txt#L3
It'll always stay that until someone changes that line.

Right now, here: https://github.com/AcademySoftwareFoundation/openapv/blob/main/src/CMakeLists.txt#L52
It sets project major and minor as version (not soversion) of the library. After this PR, it will be soversion.major.minor as library version, so the two are aligned.

The only thing not accessible in the header is the soversion, which should not ever be important for the code anyway, since it'll only be bumped very infrequently, when breaking API changes occur.
The project version derived from git tags or version.txt is what's in the header. There is no other version I'd know that could be put there.

jamrial · 2025-05-10T23:42:37Z

It sets project major and minor as version (not soversion) of the library. After this PR, it will be soversion.major.minor as library version, so the two are aligned.

So it will be liboapv.so.1.0.1, and if the next tagged release is for example 0.1.14, that soversion will not change, even if there's new API.
My suggestion is something like this: jamrial@4eefe18 to separate project from soname.

BtbN · 2025-05-10T23:48:38Z

The soname won't change ever anyway, it's just the project name.
Neither will the soversion, which is just 1.
That other just "version", without leading "so" isn't used by anything as far as I'm aware. Including the patch level at the end would be simple enough, but I'm not sure what it achieves?

Both your approach and the current one will depend on the proper maintenance of either tags or those entries in the cmakelist.

jamrial · 2025-05-11T00:16:17Z

Neither will the soversion, which is just 1.

Why would it not change? If any exported function is removed, or the offset and/or size of fields within a public struct are changed, they need to bump major soversion. Otherwise, existing binaries that linked to it will crash.

That other just "version", without leading "so" isn't used by anything as far as I'm aware. Including the patch level at the end would be simple enough, but I'm not sure what it achieves?

Not sure what other "version" you're talking about. If you mean the VERSION_{MAJOR,MINOR,PATCH} ones, those are set to the value in the git tag or version.txt, and passed to CMake to set the global standard defines PROJECT_VERSION_{MAJOR/MINOR/PATCH}. They are equal and interchangeable, afaik.
In my patch, i replace LIB_SOVERSION with LIB_SOVERSION_{MAJOR,MINOR,PATCH}, meant for versioning the library soname in a way independent from the project version.

Both your approach and the current one will depend on the proper maintenance of either tags or those entries in the cmakelist.

Well, proper maintenance is expected of any project that intends to be added to any package manager or included as dependency in another project. This one isn't excluded.
The tags are arbitrary. Just like it's 0.1.13 now the next could be 0.1.14 or 0.2.0, and it reflects nothing other than the perception that the project had enough changes to guarantee a big enough number increase. But library soversions that follow semver have a real purpose for the sake of binaries linking to your library ("Are these sizes and offsets as i expect them?", "Is this symbol present?", etc), and are not cosmetic. That's why they should be separate.

BtbN · 2025-05-11T00:21:17Z

There are two distinct versions set on the library. The soversion, which is just one single number.
This is what needs bumped on an ABI break, so prevent bad runtime behaviour.

The other is what cmake calls just "version". It controls the numbers in the other symlink. But I'm still not aware of that symlink being used for anything, so what numbers are shown there are largely inconsequential.
So what you're looking for is already in place: When ABI breaking changes are made, care has to be taken to bump the LIB_SOVERSION in src/CMakeLists.txt

Any other version, which is currently derived from tags, is more of interest to check if a certain API might exist at compile time.
It has no impact on the soversion. But it does go into said plain version of the library, where any change is inconsequential.

dkozinski · 2025-05-12T12:46:35Z

I will systematize certain things.

VERSION: This typically refers to the full version of the library and is expressed in a format like major.minor.patch (e.g., 0.1.13). It indicates the specific release of the library, including all changes, bug fixes, and new features.

SOVERSION: This should be an integer that represents the ABI version and is used to indicate whether changes in the library are backward incompatible.

This is an integer that represents the ABI version of the library.
It indicates whether changes in the library are backward incompatible.
When you change SOVERSION, you inform users that there may be compatibility issues, which is crucial when managing dependencies in projects.

In summary, SOVERSION should be a simple integer and not a full version number in the major.minor.patch format.

Currently

Currently, the names of the links to the openAPV shared library contain both the library full VERSION and the SOVERSION. It looks as follows:

1. liboapv.so:

This is the generic shared library name that points to the current version of the library.
It links to the latest SOVERSION ( liboapv.so -> liboapv.so.1 )

2. liboapv.so.1:

This file represents the SOVERSION, which is 1 in this case.
It links to the specific version of the library that corresponds to the full library version, in our case, 0.1.13 (it does not correspond to the ABI version).
( liboapv.so.1 -> liboapv.so.0.1 )

3. liboapv.so.0.1:

This file represents the full version of the library, where VERSION is 0.1.13. and it includes the major and minor numbers.

SOVERSION = 1
VERSION.major = 0
VERSION.minor = 1
VERSION.patch = 13

Proposed changes

What can we do with this?

1. Decouple the library versioning from SOVERSION (complete independence of VERSION from SOVERSION).

As proposed by Jamrial, decouple the library versioning from the ABI version.

Results:

1.1. liboapv.so

generic shared library name that points to the current version of the library. It links to the latest SOVERSION.

1.2. liboapv.so.1

it represents the SOVERSION, which is 1 in this case. It links to the specific version of the library that corresponds to the ABI version.

1.3. liboapv.so.1.0.1
This file represents the full ABI version of the library, where ABI_VERSION is, let's say, 1.1.0. [LIB_SOVERSION_MAJOR, LIB_SOVERSION_MINOR, LIB_SOVERSION_PATCH 0] This includes the major and minor numbers.

2. Make VERSION.major dependent on SOVERSION (Dependency of the minor component of VERSION on SOVERSION).

VERSION.major = SOVERSION

With each change to the public API (changes in the API interface that are incompatible with previous versions) that may cause backward compatibility issues (i.e removal of functions, change of function signatures), change VERSION.minor and SOVERSION (VERSION.minor = SOVERSION).

Results:

2.1. liboapv.so

generic shared library name that points to the current version of the library. It links to the latest SOVERSION.

2.2. liboapv.so.1

it represents the SOVERSION, which is 1 in this case. It links to the full version of the library that corresponds to the ABI version.

2.3. liboapv.so.1.0.13

This file represents the full version of the library, where VERSION is, say, 1.1.13 [VERSION.major, VERSION.minor, VERSION.patch].

This includes the major and minor numbers.

3. Last option: leave it as it is

Optionally, we can include the full version of the library 0.1.13 in the so name (liboapv.so.0.1.13 instead of liboapv.so.0.1)

1. liboapv.so:

This is the generic shared library name that points to the current version of the library.
It links to the latest SOVERSION ( liboapv.so -> liboapv.so.1 )

2. liboapv.so.1:

This file represents the SOVERSION, which is 1 in this case.
It links to the specific version of the library that corresponds to the full library version, in our case, 0.1.13 (it does not correspond to the ABI version).
( liboapv.so.1 -> liboapv.so.0.1.13 )

3. liboapv.so.0.1.13:

This file represents the full version of the library, where VERSION is 0.1.13. and it includes the major and minor numbers.

dkozinski · 2025-05-13T07:48:21Z

Personally, I opt for the solution no 1 presented by jamrial (jamrial@4eefe18) , which completely separates the versioning of the library and the ABI.

jamrial · 2025-05-13T14:53:06Z

Personally, I opt for the solution no 1 presented by jamrial (jamrial@4eefe18) , which completely separates the versioning of the library and the ABI.

It might be a good idea to make it clear somewhere other than src/CMakeLists.txt (Is there a developer guidelines document?) that new API additions, be it new symbols, enum values or defines in public headers, require a minor bump, given that it wasn't a concern until now.

jamrial · 2025-05-13T18:33:38Z

inc/oapv_config.h.in

+
+#define OAPV_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
+#define OAPV_VERSION_MINOR @PROJECT_VERSION_MINOR@
+#define OAPV_VERSION_PATCH @PROJECT_VERSION_PATCH@


What's the point in having both project and library versions here? API users only care about the latter.

I agree with @jamrial that the project version is unnecessary here.

dkozinski · 2025-05-14T10:19:31Z

Timo, please move the changes related to project configuration: shared, static to a separate PR

dkozinski · 2025-05-14T12:01:11Z

inc/oapv_config.h.in

+
+#define OAPV_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
+#define OAPV_VERSION_MINOR @PROJECT_VERSION_MINOR@
+#define OAPV_VERSION_PATCH @PROJECT_VERSION_PATCH@


I agree with @jamrial that the project version is unnecessary here.

dkozinski · 2025-05-14T12:03:40Z

src/CMakeLists.txt

-set_target_properties(${LIB_NAME_BASE}_dynamic PROPERTIES VERSION ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR} SOVERSION ${LIB_SOVERSION})
+if(OAPV_BUILD_SHARED_LIB)
+  add_library(${LIB_NAME_BASE}_dynamic SHARED ${SOURCE_FILES})
+  set_target_properties(${LIB_NAME_BASE}_dynamic PROPERTIES VERSION ${LIB_VERSION_MAJOR}.${LIB_VERSION_MINOR}.${LIB_VERSION_PATCH} SOVERSION ${LIB_VERSION_MAJOR})


BtbN · 2025-05-14T15:53:13Z

I can make a new PR with only the first or first two commits, but I cannot easily remove them from this PR, since the changes sit on top of the previous modifications of the CMakeLists.
So this PR will then effectively depend on the new one.

dkozinski

Please remove from this PR the changes that have already been made in #PR95.

dkozinski · 2025-05-15T07:09:13Z

CMakeLists.txt

-    add_definitions(-DOAPV_STATIC_DEFINE)
-endif(OAPV_APP_STATIC_BUILD)
+
+option(OAPV_BUILD_APPS "Build the included command line apps" ON)


The changes below (lines 68-82) are already in #PR95

dkozinski · 2025-05-15T07:11:33Z

CMakeLists.txt

 add_subdirectory(src)
-add_subdirectory(app)
+
+if(OAPV_BUILD_APPS)


The changes below (lines 135-137) are already in #PR95

dkozinski · 2025-05-15T07:16:30Z

src/CMakeLists.txt

+  add_compile_definitions(_IS64BIT)
 endif()

 if(ARM)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:16:53Z

src/CMakeLists.txt

-  add_library( ${LIB_NAME_BASE}_dynamic SHARED ${LIB_API_SRC} ${LIB_INC} ${LIB_BASE_SRC} ${LIB_BASE_INC}
-                                              ${LIB_NEON_SRC} ${LIB_NEON_INC} )
+  set(SOURCE_FILES ${LIB_API_SRC} ${LIB_INC} ${LIB_BASE_SRC} ${LIB_BASE_INC} ${LIB_NEON_SRC} ${LIB_NEON_INC})
 elseif(X86)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:17:20Z

src/CMakeLists.txt

+  set(SOURCE_FILES ${LIB_API_SRC} ${LIB_INC} ${LIB_BASE_SRC} ${LIB_BASE_INC})
+endif()
+
+if(OAPV_BUILD_STATIC_LIB)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:18:43Z

src/CMakeLists.txt

+set(AVX ${LIB_AVX_SRC} )
+set(NEON ${LIB_NEON_SRC} ${LIB_NEON_INC})

+if(MSVC)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:19:03Z

src/CMakeLists.txt

 #
 # Set DCMAKE_INSTALL_PREFIX to change default install prefix
 # e.g cmake .. -DSET_PROF=BASE -DCMAKE_INSTALL_PREFIX='/home/user/bin/'
+include(GNUInstallDirs)


The change is already in #PR95

dkozinski · 2025-05-15T07:19:10Z

src/CMakeLists.txt

-        ARCHIVE COMPONENT Development DESTINATION ${CMAKE_INSTALL_LIBDIR}/${LIB_NAME_BASE}
-        PUBLIC_HEADER COMPONENT Development DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${LIB_NAME_BASE}
-)
+if(OAPV_BUILD_STATIC_LIB)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:19:18Z

src/CMakeLists.txt

-install(TARGETS ${LIB_NAME_BASE}_dynamic
-        RUNTIME COMPONENT Libraries DESTINATION ${CMAKE_INSTALL_BINDIR}
-        LIBRARY
+if(OAPV_BUILD_SHARED_LIB)


The changes below are already in #PR95

dkozinski · 2025-05-15T07:19:25Z

src/CMakeLists.txt

-        RUNTIME COMPONENT Libraries DESTINATION ${CMAKE_INSTALL_BINDIR}
-        LIBRARY
+if(OAPV_BUILD_SHARED_LIB)
+  set_target_properties(${LIB_NAME_BASE}_dynamic PROPERTIES PUBLIC_HEADER "${OAPV_PUBLIC_HEADERS}")


The changes below are already in #PR95

BtbN · 2025-05-15T13:46:09Z

Like I said here and in #95, this PR depends on #95 to be merged first, since it sits on top of it. All the other changes to the CMakeList rather complex, so rebasing them to master would either lead to huge merge conflicts.

Once #95 is merged, the commit they share should vanish from here on its own.

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

This fixes compiler warnings like: warning: ‘visibility’ attribute ignored on non-class types [-Wattributes] Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

dkozinski · 2025-05-16T09:22:13Z

@BtbN I added one change to your pull request that is necessary for Android.

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dariusz-f · 2025-05-16T11:32:16Z

We just need confirmation that on Android is it ok, after that we proceed further.

kpchoi · 2025-05-17T01:53:23Z

inc/oapv.h

+// The build system used in AOSP is Soong, not CMake.
+//
+// In the Android.bp file for the liboapv project, there are no rules to generate
+// the oapv_config.h file from the oapv_config.h.in template.
+//
+// As a result, the oapv_config.h file is not available on the Android platform,
+// and consequently, the OAPV_CHECK_LIB_VERSION macro and the OAPV_LIB_VERSION_MAJOR,
+// OAPV_LIB_VERSION_MINOR, and OAPV_LIB_VERSION_PATCH definitions, which specify
+// the version of the oapv library, are not accessible to Android users.
+//
+// To make it available, it is necessary to consider adding a mechanism in the Android.bp file
+// that generates the oapv_config.h file from the oapv_config.h.in template file.
+//


Do we need to this long comments in API header?
And, I am wondering that there might not be any issue if OAPV_LIB_VERSION_MAJOR, OAPV_LIB_VERSION_MINOR, OAPV_LIB_VERSION_PATCH are not available in Android system.

…v_config.h header is not available on Android Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

- Update oapv.h to include configuration and export headers based on OAPV_CONFIG_HEADER and OAPV_EXPORT_HEADER Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

BtbN · 2025-05-20T11:59:32Z

inc/oapv.h


-/* Not available on Android due to different build system */
-#ifndef __ANDROID__
+#if defined(OAPV_CONFIG_HEADER)


Won't this lead to the header never getting included when installed, due to that define not being set anywhere but in the libraries CMakeLists?

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dariusz-f · 2025-05-21T12:56:41Z

@dkozinski it's not building correctly, need to fix it.

Latest changes isn't working correctly

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

…_HEADE Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dariusz-f

Now it's working correctly

BtbN · 2025-05-22T06:31:33Z

inc/oapv_config.h

+#define __OAPV_CONFIG_H__9876543210123456789012345678901234567890123456789__
+
+#define OAPV_LIBVERSION_HEADER 0 // 0 if the file oapv_libversion.h does not exist, otherwise 1
+#define OAPV_EXPORT_HEADER     0 // 0 if the file oapv_exports.h does not exist, otherwise 1


This is not correct, for both of those.
The checks just check for defined(), so even if defined to 0, that'll still succeed and try to include the headers.

…PORT_HEADER are defined, allowing inclusion of headers when defined as 0 Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

BtbN force-pushed the cmake_improvements branch from cff20d4 to 10205c7 Compare May 9, 2025 17:51

dariusz-f mentioned this pull request May 9, 2025

Library version defines missing in installed headers #86

Closed

kpchoi requested a review from dariusz-f May 9, 2025 20:04

BtbN force-pushed the cmake_improvements branch 2 times, most recently from 9d18e77 to c7b07f0 Compare May 10, 2025 17:56

BtbN force-pushed the cmake_improvements branch 2 times, most recently from 10f3237 to 8e4e36d Compare May 13, 2025 17:06

jamrial reviewed May 13, 2025

View reviewed changes

dkozinski reviewed May 14, 2025

View reviewed changes

BtbN force-pushed the cmake_improvements branch from 8e4e36d to 240054c Compare May 14, 2025 15:54

BtbN mentioned this pull request May 14, 2025

Make shared/static libraries configurable #95

Merged

dkozinski reviewed May 15, 2025

View reviewed changes

BtbN force-pushed the cmake_improvements branch from 240054c to 5b156dc Compare May 15, 2025 14:04

BtbN added 5 commits May 15, 2025 16:04

Unify styling of CMakeLists

d3402c8

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Fix library version to be consistent with soversion

5f36d0d

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Fix export macro ordering

ec11b3e

This fixes compiler warnings like: warning: ‘visibility’ attribute ignored on non-class types [-Wattributes] Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Generate oapv_config.h

4d1aeee

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Introduce separate library version

5b156dc

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

dariusz-f previously approved these changes May 16, 2025

View reviewed changes

BtbN force-pushed the cmake_improvements branch from f18e63d to f641654 Compare May 16, 2025 11:09

Exclude oapv_config.h header for Android platform

f641654

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

kpchoi reviewed May 17, 2025

View reviewed changes

dkozinski added 2 commits May 19, 2025 09:28

Replaced detailed comment with a concise note indicating that the oap…

846d88e

…v_config.h header is not available on Android Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

Refactor generated headers inclusion

f17871b

- Update oapv.h to include configuration and export headers based on OAPV_CONFIG_HEADER and OAPV_EXPORT_HEADER Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

BtbN commented May 20, 2025

View reviewed changes

Update header inclusion and configuration

5bcee1f

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dkozinski added 2 commits May 21, 2025 18:36

Fixed build issue

1f3332c

Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

Set correct default values for OAPV_LIBVERSION_HEADER and OAPV_EXPORT…

5505228

…_HEADE Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dariusz-f approved these changes May 22, 2025

View reviewed changes

BtbN commented May 22, 2025

View reviewed changes

Fixed issue related to checking if OAPV_LIBVERSION_HEADER and OAPV_EX…

3c85128

…PORT_HEADER are defined, allowing inclusion of headers when defined as 0 Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>

dariusz-f merged commit 00ade59 into AcademySoftwareFoundation:main May 23, 2025
5 checks passed

jamrial mentioned this pull request May 28, 2025

APV versioning changes #97

Merged

dariusz-f mentioned this pull request May 29, 2025

Versioning issues #99

Closed

Conversation

BtbN commented May 9, 2025

Uh oh!

jamrial commented May 9, 2025

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BtbN commented May 10, 2025

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BtbN commented May 10, 2025

Uh oh!

jamrial commented May 11, 2025

Uh oh!

BtbN commented May 11, 2025

Uh oh!

dkozinski commented May 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Currently

Proposed changes

1. Decouple the library versioning from SOVERSION (complete independence of VERSION from SOVERSION).

2. Make VERSION.major dependent on SOVERSION (Dependency of the minor component of VERSION on SOVERSION).

3. Last option: leave it as it is

Uh oh!

dkozinski commented May 13, 2025

Uh oh!

jamrial commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dkozinski commented May 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BtbN commented May 14, 2025

Uh oh!

dkozinski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jamrial commented May 10, 2025 •

edited

Loading

jamrial commented May 10, 2025 •

edited

Loading

dkozinski commented May 12, 2025 •

edited

Loading

jamrial commented May 13, 2025 •

edited

Loading

kpchoi May 17, 2025 •

edited

Loading