search

dotnet / source-build

A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components
MIT License
266 stars 132 forks source link

Should source-build-reference-packages use Microsoft.NET.Sdk.IL? #1595

Open dagood opened 4 years ago

dagood commented 4 years ago

dotnet/runtime produces Microsoft.NET.Sdk.IL, which:

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

MichaelSimons commented 2 years ago

[Triage] There is low ROI on fixing this. Leaving open in case investments are made in this space.