Open ericstj opened 4 years ago
@ericstj do you still think this is feasible given that we do extensive ILLink testing in sfx.proj and in oob.proj in addition to us running the linker in library mode over our compiled assemblies?
Since this issue was opened, the illink.targets logic grew as it now also handles suppression files and supports the above mentioned cases.
This issue has been marked needs-author-action
and may be missing some important information.
I'm still do not like maintaining a copy of the target. It's ok to have a targets file to contain all of our common customizations, but we should avoid duplicating the target itself. We don't keep a copy of the CoreCompile
target. Our customizations should be seen as a signal of things users might want to control in their linker usage. @eerhardt @vitek-karas @sbomer how feasible would it be to remove the customization here and rely on in-build functionality.
https://github.com/dotnet/runtime/blob/35f66ed7cb42a3fbcc2c56604c31f8a64dbe119b/eng/illink.targets
I don't see any big problems with it at first glance. It will require a little care to make sure we don't accidentally pass some unwanted options for our use case. We use the linker in a configuration that we don't consider a customer scenario ("library-mode" trimming), and it's pretty different from what the SDK does, but I agree that we should see this as a signal of what users might want to do.
We should avoid defining our own ILLink targets and instead extend/configure the shipping ones. We still have a lot that is unique to corefx (trimming libraries not apps, diffing the result) but we can avoid bugs by sharing the invokation logic from the official targets. See https://github.com/dotnet/corefx/pull/42266
/cc @sbomer @ViktorHofer @eiriktsarpalis