Open agocke opened 3 years ago
Why is the issue here, isn't this SDK issue?
The linker targets + task are owned by the linker, even if some of the code is in the SDK repo. It's easier to default to tracking all linker issues in mono/linker
Setting properties in the project file should invalidate the up-to-date check here https://github.com/dotnet/sdk/blob/58ce20521426792c7d491a9c4b0ef8ad1598b432/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L115, but I'm not sure if there's a great way to handle this for properties passed on the command-line. I guess we could add a step that writes certain properties to a file on each build, but that seems like an unfortunate workaround. Maybe I'm missing some MSBuild knowledge - is there a better way to make global properties part of the up-to-date check? @rainersigwald
No, no easy way to do this (https://github.com/dotnet/msbuild/issues/701 tracks inventing one but no work is currently planned for it). What we do for CoreCompile
is hash a set of compiler inputs and write that to disk (if changed), then use that as compiler input.
Here's where DefineConstants
was added to that, which is analogous to your scenario: dotnet/msbuild#3978.
For future reference: EnableCompressionInSingleFile
has the same problem (and there are probably many instances).
This means that changing the trim options can cause MSBuild to reuse files from previous trim operations with different settings.