source-build-reference-packages already knows how to call ilasm correctly, and has its own way to grab it. I don't think there are any improvements we'd get immediately from switching. I think there are mainly the ordinary nice results of sharing code: we simplify source-build-reference-packages, and the IL SDK may handle ilasm breaking changes (package name, flags, etc.), rather than us duplicating the changes after the fact. If source-build-reference-packages needs any more complex behavior, we could push it into the SDK so it can be reviewed/maintained by ilasm/ildasm experts.
The circular dependency is not a concern--this would be the same situation as the Arcade SDK. (And FWIW, source-build-ref-pkgs will get a deeper dependence on the Arcade SDK in 5.0.)
Thought of this while poking at https://github.com/dotnet/source-build/issues/1591 "Change source-build-reference-packages to follow the 5.0 plan as an ordinary repo". I don't think it necessarily makes sense to do in 5.0.
dotnet/runtime produces Microsoft.NET.Sdk.IL, which:
$(IlasmFlags)
)The IL SDK seems to have been in a bit of ownership limbo, but it is used in at least one other non-dotnet/runtime repo, and there are some recent plans to be careful about breaking changes: https://github.com/dotnet/runtime/issues/1338#issuecomment-604431105.
source-build-reference-packages already knows how to call ilasm correctly, and has its own way to grab it. I don't think there are any improvements we'd get immediately from switching. I think there are mainly the ordinary nice results of sharing code: we simplify source-build-reference-packages, and the IL SDK may handle ilasm breaking changes (package name, flags, etc.), rather than us duplicating the changes after the fact. If source-build-reference-packages needs any more complex behavior, we could push it into the SDK so it can be reviewed/maintained by ilasm/ildasm experts.
The circular dependency is not a concern--this would be the same situation as the Arcade SDK. (And FWIW, source-build-ref-pkgs will get a deeper dependence on the Arcade SDK in 5.0.)
Thought of this while poking at https://github.com/dotnet/source-build/issues/1591 "Change source-build-reference-packages to follow the 5.0 plan as an ordinary repo". I don't think it necessarily makes sense to do in 5.0.
/cc @dseefeld @crummel @ViktorHofer