[build] Add soversion to dxvk-native binaries

[flibitijibibo]

Part of #3451

[flibitijibibo]

Quick update to use meson.project_version() to get the major/minor version of the soname, to avoid adding new constants that need bumping for every release.

[misyltoad]

You need to update package-native.sh to handle symlinks or something, it's actually extracting like 3 copies of the .so rn.

I am also not completely confident we need soversioning? We should never be breaking ABI.

[flibitijibibo]

Will look into the symlinks soon, I don't think the artifact zip files will be able to preserve them so this would only help the tar releases.

@smcv may have a better explanation but I think this is needed in case a breakage is necessary; the unversioned .so should only be present as part of the development package.

[flibitijibibo]

Confirmed that artifactsv3 is what's causing the symlinks to get resolved, so the latest push includes a commit to tar the steamrt-sniper build. I could have sworn that the action supports using tar as the format, but even their own README suggests using tar inside of the zip to fix this, so here we are...

[smcv]

I am also not completely confident we need soversioning? We should never be breaking ABI.

Every library author says "we will never break ABI", until they find a reason to want to break ABI :-)

I can see the argument that the API and ABI of DXVK are (by design) tied to the fixed API and ABI of Windows DirectX, and therefore breaking API or ABI would defeat the purpose of DXVK. But, at the same time, the API and ABI of the WSIs is clearly less set in stone, because how those work is entirely a DXVK invention (Windows DirectX doesn't have SDL or GLFW as a backend), and I see @flibitijibibo making changes in various PRs that look like they are probably an ABI break for those. Even if you set a policy of being careful to avoid ABI breaks (after some cutoff date at which you declare the ABI to be stable), there are places where the ABI has been chosen by this project and could break.

Any time there is a change of the form "xyz has changed, old binaries must be recompiled", the SONAME needs to (be able to) change: this is just how ABI compatibility on Linux works, and it's what allows the old and new libraries to coexist until all dependent binaries have been recompiled against the new library.

If you're right about the ABI never changing, then the ABI major version (the 0 in .so.0) can stay at .0 forever, no harm is done by that, and downstreams can be confident that this project when compiled on Linux is doing "normal Linux things" and doesn't need exceptions to be made for it (analogous to how SDL2 and SDL3 will hopefully be libSDL2-2.0.so.0 and libSDL3.so.0 forever). The fact that it's following the normal pattern has value in its own right: it's a way to signal "this is normal, there is no weirdness going on here that you need to special-case".

Conversely, if you turn out to be wrong about never breaking ABI, then having the ABI major version in place provides an exit strategy to be able to accommodate an ABI break.

[flibitijibibo]

Coming from FAudio, a similar situation, I have to agree with the above - yes, the .0 is a weird quirk, but once it's done it's done and you don't have to think about it again... if anything it gives you the freedom to break if you need to, since you don't have to worry about breaking apps that link directly to .so. (This would actually be true of Source1 apps that might get forced onto Sniper, should there actually be a breakage between the bundled 1.9.x version and upstream)

Another thing that I considered was my ability to commit in writing that I could preserve the ABI - part of that commitment is being able to say that I control the ABI, and while I didn't do a 1:1 replication, I still ultimately have to concede control to MS who controls XAudio(2)'s design. While wildly unlikely, MS still technically has the right to just break the ABI, and we would have to follow along to keep up. In other words, I guess it's better to use the phrase "API contract" rather than ABI, even though they should be the same anyway.

[flibitijibibo]

Looks like the added .1 caused some problems with dxvk_so_version - any preferences on how to deal with this? Currently thinking of just making another string at the top that ignores any numbers after the first two, but maybe there's a better way to do this.

[flibitijibibo]

Obsoleted via #3834