Mono needs to stay on 1.39.9 for compatibility with Mono 6.12.x, but for
standard builds the latest is best, and 2.0.10+ is needed for GDNative support.
None is sourced by default, they will be sourced by the build script.
We use a copy of the same Git clone to ensure that `emsdk_env.sh` is
compatible, otherwise we end up with a dirty state when sourcing both.
- Base container: Fedora 32
- Mono uses version 6.12.0.102, MSBuild 16.6
- Linux builds use GCC 9
- Windows builds use Fedora 32's mingw-gcc (GCC 9)
- JavaScript uses Emscripten 1.39.9 (Mono 6.12 requires 1.39.7 but that version
fails generating .wasm, so we backport a patch to get 1.39.9)
- Install SCons 4.0.1 from pip
Provides SDKs for iOS 14.0 and macOS 10.15.
Mono is patched to fix a regression in Xcode 11.4+, still unfixed by Apple.
Another patch is backported from Unity's Mono fork to fix another issue with
the macOS 11.0 beta SDK.
Fixes missing arguments in Xcode and iOS dockerfiles, seems like some changes
were not properly committed during the last refactor.
iOS image is now based on the OSX one, as we'll need the OSX
toolchain to build the AOT cross-compiler.
We can't build the cross-compiler yet though as godot-mono-builds
doesn't support OSXCross for that part, and we will likely need
to build libclang manually beforehand too.
Builds are faster with 64 jobs instead of 1 :)
It's mostly relevant for 'make' but we also use the -j flag
for 'configure' as it can also trigger a build for external
dependencies (like llvm for upcoming iOS Mono builds).
This will also be used for iOS so it makes sense to do it all
together with the split out mono clone.
This also allows to pin the commit used more easily.
Like most programming language, in a logic statement `A && B || C`,
bash will not evaluate B if A is false (failing in our case).
Using `A && (B || C)` to prevent that.
A build error in the Windows 32-bit Mono build thus caused skipping
all subsequent `ln` statements up until `|| /bin/true`, which is used
to link only the folders which are missing from the self-built mono
prefix.
The build error still needs to be fixed but it doesn't seem to prevent
using the resulting container to build 32-bit Windows binaries.
This can be reverted once a proper fix has been deployed in upstream
Mono. No ETA yet as we're busy and it's unlikely to happen if we don't
do it ourselves :)
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
Specifying only a branch like '2019-08' is problematic if upstream commits
something between the builds of two containers.
We could make a tarball in the first container build and reuse that, but we
need the flexibility of Git for some patching in the Android and JavaScript
builds, so instead we allow specifying a git tree-ish as the third argument.
We can therefore also give a pretty version string to use for the image name
as second argument, e.g. 6.6.0.160 for bef1e6335812d32f8eab648c0228fc624b9f8357.
As we can't `git clone` a commit hash directly, we still need to provide both
branch name and then commit hash for this use case.
Cherry-pick the whole https://github.com/mono/mono/pull/16636
We were also attempting to patch the wrong folder previously (I had it
working in my local tests but committed the wrong patch when rebasing
to make the Git history pretty... :)).
