Skip to content

Add (IL)linker opt-in flag#6936

Merged
ViktorHofer merged 4 commits into
dotnet:masterfrom
ViktorHofer:AddLinkerOptIn
Feb 11, 2021
Merged

Add (IL)linker opt-in flag#6936
ViktorHofer merged 4 commits into
dotnet:masterfrom
ViktorHofer:AddLinkerOptIn

Conversation

@ViktorHofer

@ViktorHofer ViktorHofer commented Feb 10, 2021

Copy link
Copy Markdown
Member

This is similar to the compiler package which overrides what's inbox in dotnet/sdk. Exposing the illinker via a property as an opt-in to guarantee that the right package is used throughout the repository as msbuild caches tasks and even with ALC there is currently no way to prevent that.

TODO post merge:

  • Add a subscription from mono/linker --> arcade
  • Remove subscription in dotnet/runtime and enable the opt-in flag

ViktorHofer added a commit to dotnet/linker that referenced this pull request Feb 10, 2021
If the Microsoft.NET.ILLink.Tasks package is package referenced directly, overwriting `ILLinkTasksAssembly` guarantees that the SDK uses the right ILLink assembly. Github org searches didn't show any consumer of the private properties, hence removing them for simplification.

dotnet/arcade#6936 benefits from this change.
marek-safar pushed a commit to dotnet/linker that referenced this pull request Feb 10, 2021
If the Microsoft.NET.ILLink.Tasks package is package referenced directly, overwriting `ILLinkTasksAssembly` guarantees that the SDK uses the right ILLink assembly. Github org searches didn't show any consumer of the private properties, hence removing them for simplification.

dotnet/arcade#6936 benefits from this change.
@marek-safar

Copy link
Copy Markdown

Remove subscription in dotnet/runtime and enable the opt-in flag

What would be the benefit of it? The reason for the subscription is to have fast updates in runtime which with arcade won't be possible

@ViktorHofer

Copy link
Copy Markdown
Member Author

What would be the benefit of it? The reason for the subscription is to have fast updates in runtime which with arcade won't be possible

Same as for dotnet/roslyn (in regards to their compiler package), that would make sure that core repositories in the stack use a consistent version of the linker so that sourcebuild doesn't need to build multiple different versions.

to have fast updates in runtime which with arcade won't be possible

Arcade ingests roughly 3 times per week and we are fine with that pacing for the compiler package. If we need faster updates for ILLink, we can keep the subscription in dotnet/runtime.

@marek-safar

Copy link
Copy Markdown

If we need faster updates for ILLink, we can keep the subscription in dotnet/runtime.

I believe we do.

Comment thread src/Microsoft.DotNet.Arcade.Sdk/tools/DefaultVersions.props Outdated
Comment thread src/Microsoft.DotNet.Arcade.Sdk/tools/Settings.props Outdated
ViktorHofer and others added 3 commits February 11, 2021 15:36
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
@ViktorHofer
ViktorHofer merged commit 023bcee into dotnet:master Feb 11, 2021
@ViktorHofer
ViktorHofer deleted the AddLinkerOptIn branch February 11, 2021 20:08
akoeplinger pushed a commit to akoeplinger/arcade that referenced this pull request Apr 12, 2021
* Add (IL)linker opt-in flag
agocke pushed a commit to dotnet/runtime that referenced this pull request Nov 16, 2022
If the Microsoft.NET.ILLink.Tasks package is package referenced directly, overwriting `ILLinkTasksAssembly` guarantees that the SDK uses the right ILLink assembly. Github org searches didn't show any consumer of the private properties, hence removing them for simplification.

dotnet/arcade#6936 benefits from this change.

Commit migrated from dotnet/linker@7f47c0c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants