Auto-download Saigo SDK for any supported host platform by slipher · Pull Request #2010 · DaemonEngine/Daemon

slipher · 2026-10-12T08:33:39Z

I keep saying there should be a separate download for host-mode deps, so I took a shot at implementing it. Turned out to be pretty easy - those consistent naming conventions are paying off!

This PR makes the Saigo SDK automatically download for any supported host platform if USE_NACL_SAIGO is enabled. Also it fixes the Saigo toolchain file on Windows.

There are several advantages to making the SDK a separate download:

No need to download the NaCl toolchain if you are not building NaCl gamelogic.
No need to download a useless NaCl toolchain when cross-compiling.
Toolchain can be downloaded for host systems that don't have a deps package, or where the deps package being used doesn't match the real host system. (The SDK is available for more systems than the deps package.)

TODO:

Add copyright header
Maybe add a script in the spirit of external_deps/build.sh that could be used to build the SDK instead of downloading it

illwieckz · 2026-10-12T08:38:00Z

-set(PLATFORM_PREFIX "${DEPS_DIR}/saigo_newlib/bin")
+if (CMAKE_HOST_WIN32)
+	set(SAIGOSDK_BIN_EXT ".exe")
+endif()


That reminds me that I have some rework of those files in some branches (doing such thing). XD

In case this answers to this:

It would be nice to put the other deps download stuff in the same file but I don't want to cause excessive merge conflicts.

Actually my rework was also to remove from pnacl and saigo cmake toolchains what was not toolchain stuff, with helpers in a separate file.

Finally you don't need the explicit extensions?

What do you mean? Cmake is picky here; it doesn't work without that. The PNaCl toolchain also has explicit .bat.

You seems to not append .exe anymore.

Oh good catch! I overwrote the commit by pushing from two machines.

illwieckz · 2026-10-12T08:38:21Z

Very nice!

slipher · 2026-10-12T08:39:48Z

It would be nice to put the other deps download stuff in the new cmake file too, but I don't want to cause excessive merge conflicts.

illwieckz · 2026-10-12T08:42:29Z

Maybe add a script in the spirit of external_deps/build.sh that could be used to build the SDK instead of downloading it

It would be very straightforward because it would just clone the repository and call ./tools/release/build <system>-<arch>. Yet again those consistent naming conventions will pay off.

illwieckz · 2026-10-12T08:43:20Z

The script would be so small it can even be a CMake subproject:

git url
git tag (same as package)
1 command: ./tools/release/build <system>-<arch>

slipher · 2026-10-12T08:54:41Z

The script would be so small it can even be a CMake subproject:

I'm not excited to make it a CMake subproject since I had a terrible time with those things while contributing to the SDK. Anyway if the host platform is not already among the pre-build ones, it probably won't work without additional patching.

illwieckz · 2026-10-12T08:58:07Z

I'm not excited to make it a CMake subproject since I had a terrible time with those things while contributing to the SDK

That's something I can look for, but yes otherwise a two line wrapper script would do the job.

Anyway if the host platform is not already among the pre-build ones, it probably won't work without additional patching.

Sure, it's just that some open source enthusiasts like to (or be able to) rebuild everything. Cost of offering that would be abysmal.

slipher · 2026-10-12T09:02:16Z

Sure, it's just that some open source enthusiasts like to (or be able to) rebuild everything.

Right, that's why I want to add the script. I'm just saying, it wouldn't make sense to automatically attempt to build the SDK if no download is available, or something like that. Anyway anyone who is enthusiastic enough to rebuild the SDK should be rebuilding the deps too, so to me it makes sense to keep a similar workflow.

illwieckz · 2026-10-12T09:11:22Z

It would be nice to put the other deps download stuff in the same file but I don't want to cause excessive merge conflicts.

I would prefer a dedicated DaemonDepsDownload.cmake, but yes for now with the existing other branches modifying the root CMakeLists.txt, we better postpone that.

illwieckz · 2026-10-12T09:27:05Z

I keep saying there should be a separate download for host-mode deps.

I do remind this talk and I was agreeing, especially because to run a game one only has to build the engine, not the game. Also a special example was that (before we rebuilt Saigo), an macos-arm64 machine could have a macos-arm64 deps archive but a macos-amd64 PNaCl toolchain running on Rosetta2.

The only reasons I didn't work on it was because it was time I would better put on Saigo.

I just did not noticed that the Saigo release became that separate toolchain package ready to download (I even ported code from the Saigo release script to the deps build script to carry the packaging optimization lol).

It is exactly why I make special efforts to define conventions and follow them and unify things around, because in the end by following those conventions as a quality protocol, it just makes those things possible from the start.

The old PNaCl toolchain has been being shipped as part of the deps package, with the host platform for the compilers assumed to be the same as the target platform of the deps package. Experimental Saigo support has thus far required manually downloading the SDK. Now, make the Saigo toolchain auto-downloadable (if USE_NACL_SAIGO=1) independently from the target platform dependencies. This has several advantages: - No need to download the NaCl toolchain if you are not building NaCl. - No need to download a useless NaCl toolchain when cross-compiling. - Toolchain can be downloaded for host systems that don't have a deps package, or where the deps package being used doesn't match the real host system. (The SDK is available for more systems than the deps package.) The toolchain is downloaded from Github and then, like the deps package, extracted into external_deps/.

slipher · 2026-10-13T09:17:25Z

It's now ready, except that I need your and my fixes (DaemonEngine/saigo-nacl-sdk#17) to be merged so that I have a stable Git ref.

illwieckz · 2026-10-13T16:25:53Z

It's now ready, except that I need your and my fixes (DaemonEngine/saigo-nacl-sdk#17) to be merged so that I have a stable Git ref.

Now merged and released:

https://github.com/DaemonEngine/saigo-nacl-sdk/releases/tag/v20261013

So you can use the same reference for the prebuilt tarball and the source traball, starting with now! 🙂️

Add external_deps/sdk-build.sh which can be used as an alternative to auto-downloading Saigo. Like external_deps/build.sh, it builds the dependency package and installs it to the expected location. It is a thin wrapper around the saigo-nacl-sdk CMake build; if you need more control it is better to use CMake directly.

slipher · 2026-10-13T20:46:29Z

All right, I used the new release. Any hash can be used though, so it's not necessary to make a release if we're just tweaking the scripts like this.

illwieckz · 2026-10-13T21:03:48Z

Yes but it makes possible to use the exact same reference for the prebuilt tarball and the source tarball, and I wanted that to be tested. 🙂️

illwieckz · 2026-10-13T21:03:59Z

+    echo "For a list of supported platforms see ${REPO_URL}/tree/master/tools/release/conf"
+    echo "Actions:"
+    echo "  build - build all tools and libraries in the SDK"
+    echo "  install - install final build products to ${WORK_DIR}/saigosdk-<os>-<arch>_${SAIGOSDK_VERSION}/"


Terminology: we tend to use <system> not <os>.

This is the user-facing help so I think OS is easier to understand for someone unfamiliar.

Well, ”system” as a short-hand for operating system is consistent with all our other writing when we don't fully write “operating system“, and someone knowing that “OS” means “operating system” would understand what “systems” means in such context (and if the people really doesn't know that “OS” is for “operating system”, then “system” is less obscure). The fact that it's common knowledge that “OS” is “operating system” actually tells we can use “system”.

"System" as a shorthand for operating system never occurred to me. Generally I think of a system as comprising both the hardware and software components. So OS and architecture are both parts of defining a target system.

illwieckz · 2026-10-13T21:09:42Z

@@ -0,0 +1,88 @@
+#!/usr/bin/env bash


Bikeshedding from me, but it would be nice if brand new files can use tabs as indentation (same for CMake files).

illwieckz · 2026-10-13T21:10:37Z

That looks very good! Amazing! 😃️

illwieckz · 2026-10-13T22:46:05Z

I just tested this branch with the CMake download integration and it worked very well! 💯️

cmake: SAIGOSDK_ROOT configures NaCl toolchain path

7e2341f

illwieckz reviewed Oct 12, 2026

View reviewed changes

illwieckz mentioned this pull request Oct 12, 2026

external_deps: properly build native tools, make possible to loop some builds for different targets, hardlink deduplication before taring… #2004

Open

slipher force-pushed the saigosdk branch 2 times, most recently from bdc1bd2 to f996622 Compare October 13, 2026 09:14

slipher mentioned this pull request Oct 13, 2026

tools/build/release fixes for deps build script DaemonEngine/saigo-nacl-sdk#17

Closed

slipher force-pushed the saigosdk branch from f996622 to ca7eaed Compare October 13, 2026 20:44

slipher marked this pull request as ready for review October 13, 2026 20:45

illwieckz reviewed Oct 13, 2026

View reviewed changes

Conversation

slipher commented Oct 12, 2026

Uh oh!

illwieckz Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

illwieckz commented Oct 12, 2026

Uh oh!

slipher commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 12, 2026

Uh oh!

illwieckz commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Oct 12, 2026

Uh oh!

illwieckz commented Oct 12, 2026

Uh oh!

slipher commented Oct 12, 2026

Uh oh!

illwieckz commented Oct 12, 2026

Uh oh!

illwieckz commented Oct 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Oct 13, 2026

Uh oh!

illwieckz commented Oct 13, 2026

Uh oh!

slipher commented Oct 13, 2026

Uh oh!

illwieckz commented Oct 13, 2026

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!

illwieckz Oct 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

illwieckz commented Oct 13, 2026

Uh oh!

illwieckz commented Oct 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

illwieckz Oct 12, 2026 •

edited

Loading

slipher commented Oct 12, 2026 •

edited

Loading

illwieckz commented Oct 12, 2026 •

edited

Loading

illwieckz commented Oct 12, 2026 •

edited

Loading

illwieckz Oct 13, 2026 •

edited

Loading