Skip to content

Auto-download Saigo SDK for any supported host platform - #2010

Draft
slipher wants to merge 3 commits into
DaemonEngine:masterfrom
slipher:saigosdk
Draft

slipher wants to merge 3 commits into
DaemonEngine:masterfrom
slipher:saigosdk

Conversation

@slipher

@slipher slipher commented Oct 12, 2026

Copy link
Copy Markdown
Member

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

Comment thread cmake/toolchain-saigo.cmake Outdated
set(PLATFORM_PREFIX "${DEPS_DIR}/saigo_newlib/bin")
if (CMAKE_HOST_WIN32)
set(SAIGOSDK_BIN_EXT ".exe")
endif()

@illwieckz illwieckz Oct 12, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@illwieckz

Copy link
Copy Markdown
Member

Very nice!

@slipher

slipher commented Oct 12, 2026 •

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
Member

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

illwieckz commented Oct 12, 2026 •

Copy link
Copy Markdown
Member

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

slipher commented Oct 12, 2026

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
Member

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

slipher commented Oct 12, 2026

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
Member

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

illwieckz commented Oct 12, 2026 •

Copy link
Copy Markdown
Member

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/.
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

slipher commented Oct 13, 2026

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
Member

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:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants