These are some disparate notes I took while building Intuition. If anyone happens to need some help, here’s my way of giving back. Saved you a week of trying.

I need to submit some issues.

Now, here’s the anime:

First things first: the setup:

• A very underpowered laptop from 2018.
  • I don’t own a Mac, nor did I have access to one in time. This is why I did all of this, anyway.
• Debian 12 (bookworm) under WSL2.
• Weaponised hyperfocus (obligatory).

Now, the process:

• I need to compile a template to export a game to macOS.
• To get a Mac build, I need to build https://github.com/tpoechtrager/osxcross to compile the toolchain to build.
• I also need https://github.com/KhronosGroup/MoltenVK because macOS doesn’t have native Vulkan support, and MoltenVK is a translation layer over Apple’s Metal to be able to run Vulkan games over Metal.
  • It couldn’t be found by scons , the build tool for Godot. Nor did it read the env value, or the path I passed. If scons does not find MoltenVK, you need to point vulkan-sdk-pathto the folder that has the MoltenVK.xcframework file. Anything else and it won’t find it, no matter if it’s inside a folder. Took me hours to notice that little bit. Skill issue from my side.
• To compile osxcross , you need to unpack either the Xcode or Xcode Command Line Utilities file.
  • I was dumb and used the whole Xcode file.
  • pbzx could not find the file.
  • I found the unpacked files… but they targeted a version of macOS that was too old (Darwin 15,, or Mac OS X 10.11 El Capitan). I needed to target something like macOS 13 Ventura or above (Darwin 22 or above). I got Darwin 23.5 and 24 (macOS Sonoma and Sequoia).
    • I figured this out after I went through the whole compilation process and got stuck at Godot.
  • After a couple days, I figured out that using the Command Line Tools and gen_sdk_package_tools_dmg.sh could extract the file onto a tarball.
  • Then I had to recompile LLVM and Clang for some obscure reason. The reason is further down… but the thing is: the download link was broken. A newer version was available, so I edited the script because the links are hard-coded.
  • After that, and some weird troubleshooting, oscross compiled the whole toolchain.
• Then I needed to compile Godot itself.
  • For some reason, and this is where it gets messy: I had some very weird compilation issues. It failed at very random points.
    • Turns out Clang 19 has stricter requirements (281868 – graphics/embree: fix build with clang 19) and it was fixed later… well I ended up compiling the compiler frontend. Which is pretty much one step removed from going all the way down.
    • Debian, by design, has older but more stable releases of packages. Sometimes they are too old, like their version of LLVM. I don’t remember if this was skill issue or not, but I compiled LLVM 19 as well. 17 did not work for some reason.
      • Should’ve used Arch btw.
  • It also failed to compile a lot of built-in libs. The part in the docs where they mention turning off some libraries helps a lot.
    • You may encounter some extra failures on some certain files. This depends a lot on the compiler you’re using. Usually the Linux one is the easier to build. However:
      • If you have issues with Linux for some reason, use LLVM.
      • If you have issues with Windows, use llvm-mingw (https://github.com/mstorsjo/llvm-mingw) hope you’re comfy compiling toolchains!
      • Now, with macOS. This one is near impossible to build unless the osxcross toolchains are just right. The things that kinda got me further down are: using Apple Clang and recompiling with them.
      • For all of the above, usually you wanna do a scons --clean in between.
    • If you use .NET like me (my most sincere condolences):
      • The docs don’t really make it clear, but the command <godot_binary> --headless --generate-mono-glue modules/mono/glue does imply two things: you’re in the root folder of the repo, and you’re running this on Linux. <godot_binary> is the file you just compiled (or any, for that matter). If it’s fresh out of the compiler, it’s bin/<godot_editor_with_mono_suffix> —headless —generate-mono-glue <path_to_modules/mono/glue> . If you execute it from /bin , you will get the files on a folder called modules inside the bin folder. It will fail the next step if you leave it like this. Make sure the last argument _points to modules/mono/glue . Ironically, the next step is clearer about this tiny little misunderstanding.
        • This issue applies mostly if you build under Windows.
      • You need to generate the NuGet packages. You need to create the source. I don’t even know why they make this optional. If you don’t, Godot won’t be able to compile your game and you’re gonna get an error.
      • The order I go at it:
        • Build a Linux editor with all your extra spicy args on top.
          • Mine ended up being: scons platform=linuxbsd target=template_release module_mono_enable=yes vcproj=yes gen_vcproj_only=no debug_symbols=no production=yes use_gcc=no use_llvm=yes. If you’re targeting Windows, it doesn’t matter if you choose LLVM, it’s going to use mingw anyways.
          • dotnet nuget add source <absolute_path_to_folder_usually_./nuget/NuGet/bin/NameOfSource> --name NameOfSource . I always messed the order of the dotnet arguments.
          • In the root of the Godot folder, run: bin/godot.linuxbsd.editor.x86_64.mono —headless —generate-mono-glue modules/mono/glue .
          • Now, move to modules/mono/build_scripts and then run the final command as python3 build_assemblies.py —godot-output-dir=absolute/address/to/bin/folder —godot-platform=linuxbsd
            • Why change the addresses? Because I had some problems using relative addresses. It either didn’t find it, I had problems with my Python env, or it opened the Python file instead of executing it, if you were doing all this under Windows.
            • Since this build is for Linux, I used the linuxbsd platform. The binaries are universal. But cross-compiling from WSL worked so much better than doing it natively.
          • Now you have a fresh GodotSharp and NuGet packages! Save these for later.
          • Now, build the Windows .NET editor. The previous step took care of the .NET stuff.
          • Build the templates.
          • Done!

The final command I tried for macOS was:

export OSXCROSS_ROOT:"/absolute/path/to/osxcross/root/folder:$PATH"
scons \ 
target=template_release \
debug_symbols=no \
module_mono_enabled=yes \
production=yes \
platform=macos \
vulkan_sdk_path=/folder/to/MoltenVK.xcframework \
osxcross_sdk=darwin24 \
builtin_embree=no \
builtin_enet=yes \
builtin_freetype=no \
builtin_graphite=no \
builtin_harfbuzz=no \
builtin_libogg=yes \
builtin_libpng=no \
builtin_libtheora=yes \
builtin_libwebp=no \
builtin_mbedtls=yes \
builtin_miniupnpc=no \
builtin_zlib=no \
generate_bundle=yes

Your mileage may vary depending on what you do.

This is not a guide.