Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish ILC as a trimmed+R2R+singlefile executable #73987

Merged
merged 2 commits into from
Aug 16, 2022

Conversation

MichalStrehovsky
Copy link
Member

This is the same configuration that we ship crossgen2 with on platforms that don't have NativeAOT. It produces a lot smaller packages with faster startup time. Setting this as CoreCLRILCompilerDir ensures that this is the ILCompiler that we test, build crossgen2 with, and package.

I don't have high confidence that we can get #67742 in time for .NET 7 but since we still have some runway before .NET 7 snaps, proposing checking this in as a plan B.

This change would be temporary until #67742 is fixed.

Cc @dotnet/ilc-contrib

This is the same configuration that we ship crossgen2 with. It produces a lot smaller packages with faster startup time. Setting this as `CoreCLRILCompilerDir` ensures that this is the ILCompiler that we test, build crossgen2 with, and package.

I don't have high confidence that we can get dotnet#67742 in time for .NET 7 but since we still have some runway before .NET 7 snaps, checking this in as a plan B.

This change is temporary until dotnet#67742 is fixed.
@MichalStrehovsky
Copy link
Member Author

/azp run runtime-extra-platforms

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

<Target Name="PublishCompiler"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the publish going to use live-built runtime or the LKG runtime from https://github.com/dotnet/runtime/blob/main/global.json ?

If it is the later, is this going to have fallout for servicing and source build?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's using the LKG.

We update the LKG as part of servicing, so the expectation is that we'll ship this on top of RC1 (like we did .NET 6), and upgrade to RTM for the next servicing release (we'll be always a build behind).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But yes, this would definitely be an issue for source build and doing #67742 would be a ship blocker then. I have another email thread on the fate of source build. People above my paygrade need to make decisions on what to keep in 7.0.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Thank you!

@MichalStrehovsky
Copy link
Member Author

I went through all the failures in the relevant pipelines - all tests are passing per the console logs.

But if something was broken by this, we wouldn't get to running tests in the first place.

@carlossanlop
Copy link
Member

I don't have high confidence that we can get #67742 in time for .NET 7 but since we still have some runway before .NET 7 snaps, proposing checking this in as a plan B.
This change would be temporary until #67742 is fixed.

@MichalStrehovsky @jkotas just so you know, this change will go into RC1 since we had to delay the snap for a full day. Considering your comment quoted above, please make sure to submit a backport of the actual fix to RC1 or later to RC2.

@ghost ghost locked as resolved and limited conversation to collaborators Sep 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants