I've added a function to the mono.eclass that supports generating ahead-of-time natively compiled binaries from IL binaries. I've tested it with the mono and art-sharp ebuilds, and it seems to work. This AOT compilation greatly speeds up applications (monodevelop went from unusable to fairly smooth for me), and emerge-time, IMHO, is the right time to generate these binaries. Furthermore, doing it in the ebuild means that the resulting .so files will be managed by the portage system, and not left around as cruft if/when packages are uninstalled. Reproducible: Always Steps to Reproduce: 1. Emerging any dot net application Actual Results: IL binaries are installed Expected Results: Native bytecode should be generated and installed alongside the IL (eclass will follow)
Created attachment 60081 [details] An extended mono.eclass that contains a function to precompile IL to native bytecode This eclass doesn't solve the problem on its own. Dot net ebuilds will still need to call the precompile-il function in order to generate native binaries.
Created attachment 60082 [details] Example of an ebuild utilizing the IL precompilation function This is about as trivial as an example can be. Pretty much, the precompile-il function needs to be called after the application has been installed to the image directory and before merging.
Created attachment 60083 [details] An extended mono.eclass that contains a function to precompile IL to native bytecode This version is controlled by a USE flag (mono-precompile). This is desireable, as not everyone may want to go through the up-front overhead of precompiling their .NET binaries into a native format. Naturally, this flag would have to be documented in use.desc; I don't know who'd do that, but the blurb would be something like: mono-precompile - Use mono to ahead-of-time compile dot net packages to native code before installation
Interesting, why not make it more accessible by creating a mono_src_install function ?
I believe I talked to Travis about this on IRC, but for posterity I'll add this here as well. I'm all for this in concept, but in practice we need to be very careful with this. AOT is still one of the more experimental/untested features, and can introduce strange breakage. Secondly, it currently only really works on x86, so this definitely needs to take the arch issue into effect. I definitely think this is something we should pursue, but it needs lots of testing, and mono may not quite be ready for this.
