-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Make InstallRuntimeComponentToFinalDestination use NativeOutputPath for copying to runtime output #100782
Conversation
@@ -69,7 +69,7 @@ | |||
|
|||
<Target Name="InstallRuntimeComponentToFinalDestination" | |||
AfterTargets="CopyNativeBinary" | |||
DependsOnTargets="CopyNativeBinary;StripLibraryLikeCoreCLRBuild" Condition="'$(IsRuntimeComponent)' == 'true'"> | |||
DependsOnTargets="CopyNativeBinary;_CopyAotSymbols;StripLibraryLikeCoreCLRBuild" Condition="'$(IsRuntimeComponent)' == 'true'"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichalStrehovsky @agocke is there a better / public target to chain into instead of _CopyAotSymbols
for running something after NativeAOT symbols are copied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can it be copied from bin\[config]\[framework]\[rid]\native
($(NativeOutputPath)
) instead? That one should be available after LinkNative
already, we don't even need to run Publish. Looks like this is making three copies of the symbols. We could get away with two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to using NativeOutputPath
and depending on LinkNative
.
we don't even need to run Publish. Looks like this is making three copies of the symbols. We could get away with two.
Agreed, we should be able to avoid this. In the interest of just unblocking codeflow, I didn't try removing the publish in this PR - will also look at that as a folllow-up along with using either the live or versions.props version of the tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM to unblock the codeflow but I still see double writes in the binlog with this.
Isn't that expected? |
The double write is in the output, i.e. the .pdb, and this is Windows so we don't run |
I believe the double writes are because of:
#98342 fixed the double writes, so once we update the src/native/managed infrastructure to use a version with the fix, that should also avoid the double writes. |
…or copying to runtime output (dotnet#100782) The InstallRuntimeComponentToFinalDestination target from infrastructure for NativeAOT-ed runtime components (dotnet#98565) copies the component and symbol files to the runtime output directory. Make the target use NativeOutputPath for the for the library and symbol path instead of the ones copied to the publish directory. They should be available after LinkNative. This was working in the runtime repo because the projects under src/native/managed are currently using the ILCompiler package corresponding to the SDK being used to build the repo. That version of the package doesn't have dotnet#98342 - the native-library.targets were relying the symbols already being copied before _CopyAotSymbols was run.
The
InstallRuntimeComponentToFinalDestination
target from infrastructure for NativeAOT-ed runtime components (#98565) copies the component and symbol files to the runtime output directory. Make the target useNativeOutputPath
for the for the library and symbol path instead of the ones copied to the publish directory. They should be available afterLinkNative
.This should unblock dotnet/installer#19333
This was working in the runtime repo because the projects under src/native/managed are currently using the ILCompiler package corresponding to the SDK being used to build the repo. That version of the package doesn't have #98342 - the native-library.targets were relying the symbols already being copied before
_CopyAotSymbols
was run.I think the infrastructure should use the live ILCompiler if possible, otherwise the version in Version.Details.xml/Version.props instead. This PR does not try to do that - will look into it separately.