Question about the process of porting NativeAOT to Consiles about fna

[TheSpydog]

At a high level, the NativeAOT toolchain works like so:

1. Compile the managed IL into an object file for a particular OS/architecture
2. Compile a C++ "bootstrap" source file that provides the actual main function
3. Compile all the C/C++ .NET runtime native libraries (Runtime, System.Globalization.Native, etc.)
4. Link all of the above into the final executable

We have our own way of dealing with these steps for consoles, which allows us to reuse most of upstream .NET and not have our own custom forks of dotnet/runtime.

Even for consoles, Part 1 is completely handled by upstream .NET -- we don't need to touch the ILCompiler at all. We just tell it to spit out object files for linux/windows-x64/arm64 (depending on the platform). That's the hardest part taken care of!

Part 2 is also pretty straightforward. For each console, we take the official Bootstrap.cpp and tweak it slightly for any platform-specific idiosyncrasies around initialization.

Part 3 is where it gets interesting. We use as many official .NET source files as we can, and only add/substitute our own when absolutely necessary. The general process is the following:

1. Create a VS project for each native library for the given console, using the upstream CMake build system as a guide. (Which files need to be included in the project, what preprocessor definitions need to be set, etc.)
2. Attempt to build the project, as-is.
3. For each compile error, evaluate what can be done to fix it. Imagine that one of the consoles doesn't support the POSIX function fread. In that scenario, we'd need to either create our own versions of each source file that uses fread and replace it with a console-specific API call, or we can hack in fread support via preprocessor trickery. (#define fread MySpecialFreadFunction implemented elsewhere in the project.)
4. Repeat (3) until the project compiles successfully.

Part 4 is similar to Part 3, but focused on linker errors instead.

When there's a new version of .NET, we basically just git pull the latest .NET release tag and check where we get compile/link errors in the console projects, then update our console code accordingly. The APIs used by .NET native libraries are not stable, so we often have to update a bunch of function signatures to get it to build again. This is not typically a huge effort, just a few days of tedious work.

One thing that's very important to us on the FNA team is that the NativeAOT console projects are shared freely (or, as freely as they can be with NDAs). Ideally, there should be one singular repository for each console that is shared by FNA, MonoGame, Godot, Raylib-CS, and any other interested parties. We're trying to push for that, so we'll see how that goes.

[KUNGERMOoN]

Thanks, very interesting stuff!
I'm glad there's finally a good, scalable approach for running C# on consoles

Ideally, there should be one singular repository for each console that is shared by FNA, MonoGame, Godot, Raylib-CS, and any other interested parties. We're trying to push for that, so we'll see how that goes.

I remember reading something similar in the flibitPlan, and I'm very happy this is still the case.
While I don't plan to use FNA for my project, I must admit you do a really good job for the entire C# gamedev community, and I wish you all good luck going forward :)

[KUNGERMOoN]

Also, do you know if this approach could be used to possibly port NativeAOT-Mint for consoles when/if it gets out of the experimental phase?

It could be used for many interesting things, and maybe even something close to modding on consoles