Open ViktorHofer opened 4 years ago
Tagging subscribers to this area: @safern, @viktorhofer See info in area-owners.md if you want to be subscribed.
We currently pull the crossgend version of CoreLib when building libraries in Release.
I do not think this is useful to crossgen for developer inner loop. The inner loop should use non-crossgened CoreLib. Yes, it will make the inner loop different from the full stack build and test, and that's fine.
Yes, it will make the inner loop different from the full stack build and test, and that's fine.
I don't think this is useful for developer innerloop as well besides for perf measurements of incremental changes. If we don't care about that scenario too much, then I'm fine with not crossgening in incremental builds.
Unrelated, we still don't crossgen other shared framework libraries than CoreLib when testing in CI. So we are already inconsistent here.
A few months ago we switched from a named reference for
System.Private.CoreLib
to a ProjectReference so that we can build libraries without needing to buildSystem.Private.CoreLib
via the coreclr/mono.corelib subset first. This works as expected and improved the developer innerloop as CoreLib is now incrementally built as a dependency of libraries.So far so good. We would now like to also binplace CoreLib incrementally into the testhost and runtime pack (as any other managed library under libraries) so that we don't need to invoke externals.csproj (libs.pretest subset) to update the testhost and the runtime pack. Basically we would like to switch from a pull to a push model to improve the developer innerloop workflow.
Why we haven't done this yet and what makes this less trivial are the following nuances:
coreclr.dll
is compiled with the Debug configuration, CoreLib needs to be built in that configuration as well./p:Coverage=true
). What makes this even more difficult is that we would need to make sure that crossgening CoreLib is fast and that crossgen itself is already built. Also crossgen vs crossgen2?Raising this now as the Mono team asked for this actively and as it would improve the developer innerloop workflow: https://github.com/dotnet/runtime/commit/792fd1df1894200a159a3fc0d03eeda3c400cc3e.
Related: https://github.com/dotnet/runtime/issues/38034
cc @jkotas @ericstj @akoeplinger @safern @dotnet/runtime-infrastructure