[jsonifier, discordcoreapi] Fix build hangs and warnings.

[BillyONeal]

2 potential causes:

• At least in my testing, build requires >9GB per thread of memory, which might have been 'hanging' by causing the OOM killer to kill the agent.
• There are 'sub' CMake builds which write to the source tree and stomp on each other.

Related: RealTimeChris/Jsonifier#35
Related: #40229

[BillyONeal]

I'm hoping this also fixes the build being very very slow on osx:

since this is forcing those machines into heavy swap use.

[BillyONeal]

/cc @RealTimeChris

[dg0yt]

/cc @RealTimeChris

TBH discordcoreapi is fairly strange CMake code.
The port should be disabled in CI, if not delisted, until revised.

As an addtional note, the package optimizes for the capabilities of the physical host CPU. It is unable to cross-build.

Taking a second look, this trouble starts at jsonifier.

(I do acknowledge that the source code offers excellent optimizations. I'm unhappy with CMake code and the ports.)

[RealTimeChris]

The build taking a long time/extreme RAM consumption should be fixed by the new tuple implementation I've added to Jsonifier since its last release. Let me push the changes to main.

[RealTimeChris]

/cc @RealTimeChris

TBH discordcoreapi is fairly strange CMake code. The port should be disabled in CI, if not delisted, until revised.

As an addtional note, the package optimizes for the capabilities of the physical host CPU. It is unable to cross-build.

Taking a second look, this trouble starts at jsonifier.

(I do acknowledge that the source code offers excellent optimizations. I'm unhappy with CMake code and the ports.)

You can cross-compile, you just need to set JSONIFIER_CPU_INSTRUCTIONS flag to correctly align with whichever target CPU architecture you're compiling for.
https://github.com/RealTimeChris/Jsonifier/blob/main/Documentation/CPU_Architecture_Selection.md

[BillyONeal]

Looks like this fixed the warnings on Windows, taking forever on macOS, and the OOM killer on Linux:

Elapsed time to handle discordcoreapi:x64-osx: 1 min
Elapsed time to handle discordcoreapi:x64-linux: 35 s

[BillyONeal]

TBH discordcoreapi is fairly strange CMake code.
The port should be disabled in CI, if not delisted, until revised.

I agree that, for example, invoking a sub complete CMake build is a little unorthodox, but unless it is causing problems for other ports I don't think it should be deindexed for that.

As an addtional note, the package optimizes for the capabilities of the physical host CPU. It is unable to cross-build.

That's true, but it's hardly the only port to do that. I don't think we have settled on a great answer to this situation: It's true that changing stuff based on the host CPU is bad for binary caching, but the alternative of force disabling all such optimizations makes ports that care about doing this useless for their customers much of the time, so we haven't tried to ban it despite the potential issues.

The build taking a long time/extreme RAM consumption should be fixed by the new tuple implementation I've added to Jsonifier since its last release. Let me push the changes to main.

Awesome, thanks!

[dg0yt]

You can cross-compile, you just need to set JSONIFIER_CPU_INSTRUCTIONS flag to correctly align with whichever target CPU architecture you're compiling for.

I started to study this already.

Jsonifier comes as header-only. It shouldn't need to commit to a particular CPU, but it burns the host CPU type into a header. Even worse, it forces its compile flags on consumers. -march=native (GNU, CLANG) as well as /fp:fast (MSVC).

[RealTimeChris]

You can cross-compile, you just need to set JSONIFIER_CPU_INSTRUCTIONS flag to correctly align with whichever target CPU architecture you're compiling for.

I started to study this already.

Jsonifier comes as header-only. It shouldn't need to commit to a particular CPU, but it burns the host CPU type into a header. Even worse, it forces its compile flags on consumers. -march=native (GNU, CLANG) as well as /fp:fast (MSVC).

My mistake the -march=native should have never been in there and I've removed the /fp:fast from msvc. Also I will look into trying runtime methods for detecting the CPU architecture, as long as it doesn't ruin performance.