MStrehovsky
Joined 6 years ago
Joined 6 years ago
[1] https://learn.microsoft.com/dotnet/core/deploying/native-aot... [2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f... [3] https://learn.microsoft.com/dotnet/core/deploying/native-aot...
The tooling already generates warnings for any spot in the program that uses reflection _in a way that cannot be statically analyzed_. Fixing code to make it work with trimming is equivalent to fixing warnings. Here are a couple case studies: https://devblogs.microsoft.com/dotnet/creating-aot-compatibl...
Don't get me wrong, I like MSBuild and even bflat is built with MSBuild (wrote a custom target to invoke bflat from MSBuild), but sometimes I really just want to write a Makefile and be done with it instead of fiddling with MSBuild targets.
bflat integrates nicely with Make or other build systems - pass `-c` to generate object files (link it later with the commands bflat would use - use `-x` to see the commands), or use `bflat build-il` to create .NET assemblies and pass those as a reference (`-r`) to `bflat build` later.
It's a bunch of work to even get a hobbled version of crosscompilation to macOS running.
The way exceptions are done in .NET is by keeping track of extra metadata to be able to unwind methods (remove them from the execution stack) and execute handlers. That way the overhead of exception handling is close to zero if no exception is ever thrown. This requires quite a bit of infrastructure.
Propagating exceptions as error codes would come with execution time costs even if no exception is thrown and would have to be written from scratch (since .NET doesn't do it this way).
Either approach requires more investment than I'd want to put into it right now.
C#: 945 kB Go: 2174 kB
Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.