CMake improvements, add 64-bit support for use in Xash3D FWGS

[a1batross]

This is my attempt to finally upstream Xash related changes to ReGameDLL_CS, mostly much cleaner than everything that was used before.

In Xash3D FWGS we support 64-bit targets, but it requires a bit of work from game's side, mainly to resolve string_t issues. Engine provides a string pool with deduplication mechanism, to keep string_t 32-bit.

Not only that, to allow binaries installed and distributed for multiple platforms, we add a carefully encoded suffix at the end of the binary name. The engine expects it and only looks for properly named binaries, so cs.so becomes cs_arm64.so on Linux ARM64 targets, or cs_freebsd_riscv64d.so on 64-bit FreeBSD RISC-V with double float precision. Android is the only exception here, as mismatching CPU architecture and ABI is nearly impossible there, and server game libraries are called libserver.so there.

Along with it, it also adds some improvements to the CMakeLists.txt, mainly disabling strip if we're compiling in debug mode (which should probably be replaced with CMAKE_BUILD_TYPE checks instead) and more reliable compiler checks by using CMAKE_CXX_COMPILER_ID provided by CMake itself.

Changes to properly support non-x86 targets will follow up later.

Thank you all for this impressive project.

[a1batross]

Bump? :)

[dystopm]

Bump? :)

Main dev has health issues atm, be patient.

[a1batross]

Bump? :)

Main dev has health issues atm, be patient.

Oh, that's not fine, there is no hurry. Let him get well soon. 🙏🏽

[anzz1]

Changes to properly support non-x86 targets will follow up later.

Such large architectural changes and overall all the Xash-related stuff is better suited to live in a separate branch or better yet a fork which can then merge changes from ReGameDLL downstream.

Pushing Xash stuff to the official GoldSrc upstream is nonsense in my opinion. It comes with the implication when introducing Xash compatibility to the upstream repo, that now all changes need not to break Xash and would have to be tested with it. This should not be of purview of the official client based repo, and should be the purview of downstream fork which deals with compatibility issues.

[a1batross]

@anzz1 I disagree. The changes are non-invasive as possible and I'm not asking for developers to test anything on Xash, I will easily do this myself.

Being non-invasive is the reason why I decided to leave 64-bit ABI as is, because it doesn't require redefining string_t to a different type.

[anzz1]

I still don't understand what is the issue of keeping the Xash-related stuff downstream.
Git is specifically well suited for such things, forks, feature branches, etc. to keep a project's scope limited and easily handled and not ballooning to everything and the kitchen sink.

With GitHub Actions you can even set automatic merges from upstream to downstream, to feature branches, etc. if you want to automate it.

Example for such workflow can be found here in a set of feature branches for a WoW private server: https://github.com/TrinityCore/TrinityCoreCustomChanges

If you consider what this project is, Reverse-engineered gamedll (mp.dll / Counter-Strike), it's exactly that and nothing more or less. Keep it simple, smart.

GoldSource development can progress here in this main upstream without any hindrance nor contributors needing to have any experience or knowledge about Xash, while downstream Xash fork can merge those changes, while testing and maintaining the Xash compatibility part of it? Why change this paradigm which is exactly what Git is best for?

[a1batross]

I know this, right? I had 10 years of downstreaming regamedll and that never was a serious code changes. That's why I want it to be upstreamed, there is nothing scary about Xash. вт, 4 мар. 2025 г., 06:56 anzz1 ***@***.***>:

…

I still don't understand what is the issue of keeping the Xash-related stuff downstream. Git is specifically well suited for such things, forks, feature branches, etc. to keep a project's scope limited and easily handled and not ballooning to *everything and the kitchen sink*. With GitHub Actions you can even set automatic merges from upstream to downstream, to feature branches, etc. if you want to automate it. Example for such workflow can be found here in a set of feature branches for a WoW private server: https://github.com/TrinityCore/TrinityCoreCustomChanges If you consider what this project is, *Reverse-engineered gamedll (mp.dll / Counter-Strike)*, it's exactly that and nothing more or less. Keep it simple, smart. GoldSource development can progress here in this main upstream without any hindrance nor contributors needing to have any experience or knowledge about Xash, while downstream Xash fork can merge those changes, while testing and maintaining the Xash compatibility part of it? Why change this paradigm which is exactly what Git is best for? — Reply to this email directly, view it on GitHub <#1053 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYQTALW2ZU4ETD4355LBP32SUQANAVCNFSM6AAAAABXDKBOTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGEZDOOJWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: anzz1]*anzz1* left a comment (rehlds/ReGameDLL_CS#1053) <#1053 (comment)> I still don't understand what is the issue of keeping the Xash-related stuff downstream. Git is specifically well suited for such things, forks, feature branches, etc. to keep a project's scope limited and easily handled and not ballooning to *everything and the kitchen sink*. With GitHub Actions you can even set automatic merges from upstream to downstream, to feature branches, etc. if you want to automate it. Example for such workflow can be found here in a set of feature branches for a WoW private server: https://github.com/TrinityCore/TrinityCoreCustomChanges If you consider what this project is, *Reverse-engineered gamedll (mp.dll / Counter-Strike)*, it's exactly that and nothing more or less. Keep it simple, smart. GoldSource development can progress here in this main upstream without any hindrance nor contributors needing to have any experience or knowledge about Xash, while downstream Xash fork can merge those changes, while testing and maintaining the Xash compatibility part of it? Why change this paradigm which is exactly what Git is best for? — Reply to this email directly, view it on GitHub <#1053 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYQTALW2ZU4ETD4355LBP32SUQANAVCNFSM6AAAAABXDKBOTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOJWGEZDOOJWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SNMetamorph]

Such large architectural changes

Where is it large? Did you even see PR diff before writing such a mess?

[nekonomicon]

Reverse-engineered gamedll

Actually not %)

official GoldSrc upstream

There nothing official.

Where is it large? Did you even see PR diff before writing such a mess?

@a1batross probably ruined build scripts %)