WIP: example of implementing external deps for extra platforms #1823
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Makes it possible to build the deps for a linux-riscv64 build, it's only useful for a server as NaCl isn't working. It's used as an example of how we can implement and unlock systems we don't support. Such systems are meant to be listed as “extra”. In that context, “supported” means we provide a release binary in the unizip, while “extra” means we don't prevent someone to build it and run it if that works for him.
…not use libs from them
- Add an option to not build and link against libraries from external_deps
* Purposed to make possible to build on linux using system-provided SDL3
instead of the one in DEPS, in the rare case the system already provides SDL3.
* Purposed to make possible to build on macos-arm64 using the macos-amd64 deps
archive to find the NaCl runtime, relying on the system (example: brew) to
find libraries.
* Purposed to make possible to build on freebsd using the linux deps
archive to find the NaCl runtime, relying on the system to
find libraries.
- Use the macos-amd64 deps on macos-arm64 only if the user didn't provide
a macos-arm64 deps folder by himself.
- Use the linux deps on freebsd only if the user didn't provide
a freebsd deps folder by himself.
- Use the deps folder if the user provided it by himself, even if we don't
know yet about this system or architecture or we don't support that.
Do not set an empty -march= option when attempting to build on an unknown system. We only print a warning when attempting to build on an unknown system, so this should not expect it is never built for an unknown system.
Do not cross-compile pkgconfig, it is part of the cross-compilation toolchain.
|
Some commits are good to get even outside of the effort to enable those platforms, like:
But those aren't needed for the release either. They can be merged separately, but there is no urge to do so. |
illwieckz
force-pushed
the
illwieckz/deps-extra
branch
2 times, most recently
from
03807dc to
b06d29d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
My test bed for #1822, so it includes #1822:
While I would like to see #1822 merged for the release (it makes releasing easier), those changes aren't needed for the release. There is no urge.
But this way curious people can already know about it and if they want, toy with it.
This adds:
linux-riscv64-default, I tested building the deps, building the engine and the game dll against the deps, and run both the client and the server and it is working (except there is no nacl support).macos-arm64-default, I only tested building the deps (they build), I haven't tested building the engine against them, and then I haven't tested running the engine. The purpose is to make it easier for the user to build a native arm64 engine, only using amd64 binaries for the nacl loader.freebsd-amd64-default, the deps build without error but I know OpenAL isn't properly linked, building the linux nacl runtime on FreeBSD is probably an impossible task, so that's more a demo for now. It can probably already be used to build a static server engine to run some native server game code.