Repository navigation
Conversation
| set(PLATFORM_PREFIX "${DEPS_DIR}/saigo_newlib/bin") | ||
| if (CMAKE_HOST_WIN32) | ||
| set(SAIGOSDK_BIN_EXT ".exe") | ||
| endif() |
There was a problem hiding this comment.
That reminds my I have some rework of those files in some branches (doing such thing). XD
There was a problem hiding this comment.
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.
|
Very nice! |
|
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. |
It would be very straightforward because it would just clone the repository and call |
|
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. |
That's something I can look for, but yes otherwise a two line wrapper script would do the job.
Sure, it's just that some open source enthusiasts like to (or be able to) rebuild everything. Cost of offering that would be abysmal. |
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. |
I would prefer a dedicated |
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 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.
|
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! 🙂️ |
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:
TODO:
external_deps/build.shthat could be used to build the SDK instead of downloading it