-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[libraries] Build lib-runtime-packs for all of mono, not just mobile #35295
Conversation
Tagging subscribers to this area: @ViktorHofer |
Tagging subscribers to this area: @directhex |
69d7d13
to
33e2e93
Compare
33e2e93
to
7bb8bca
Compare
@@ -50,7 +50,12 @@ | |||
<UseHardlink Condition="'$(_runtimeOSFamily)' == 'FreeBSD'">false</UseHardlink> | |||
</PropertyGroup> | |||
|
|||
<ItemGroup> | |||
<ItemGroup Condition="'$(RuntimeFlavor)' == 'Mono'"> | |||
<HostFxFile Include="@(StoreTestHostFiles)" Condition="'%(StoreTestHostFiles.Filename)' == '$(HostFxrFileName)'" /> |
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.
Isn't this going to include dotnet
and hostfxr
in the runtime packs?
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.
I commented incorrectly the last time, so trying again ;-).
We won't be including dotnet
and hostfxr
into the runtime packs because we are excluding them from ReferenceLocalCopyPaths
and putting them into StoreTestHostFiles
. We want to do this because desktop mono is in a state where we need in tree runtime packs, but also need to make sure testhost keeps working (for now).
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.
Last time that I ran the builds for mobile/mono both dotnet
and hostfxr
were excluded from lib-runtime-packs. When building for mono, dotnet
and hostfxr
existed in testhost
. When building for mobile, neither were in testhost
.
When using your suggested changes, the same functionality was achieved.
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.
Ah right. I somehow got confused by the fact that we were copying them over to the test host 😄
@@ -98,7 +103,11 @@ | |||
DependsOnTargets="ResolveRuntimeFilesFromLocalBuild" | |||
AfterTargets="AfterResolveReferences;FilterNugetPackages" | |||
Condition="'$(RuntimeFlavor)' == 'Mono'"> | |||
<ItemGroup Condition="'$(BinPlaceTestRuntimePack)' != 'true'"> | |||
<ItemGroup> |
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.
Once you do what I suggested here: https://github.com/dotnet/runtime/pull/35295/files#r416829953 You can remove this ItemGroup
and then move the TargetsMobile != true
condition to the target itself.
Condition="'$(RuntimeFlavor)' == 'Mono' and '$(TargetsMobile)' != '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.
thanks!
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.
I think I might have just broken the tests with this suggestion 😄. Because you're adding RuntimeFiles
to ReferenceCopyLocalPaths
and then removing them in SetupTestingHost
. Let's instead change how these targets are hooked up.
Add DependsOnTargets=OverrideRuntimeMono
to SetupTestingHost
target and bring back what you had.
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.
Ah okay will change this now. I was wondering if it was breaking because I forgot the '$(RuntimeFlavor)' == 'Mono'
check.
Just wondering, what in the build errors in CI would indicate its caused by changes in this PR?
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.
Because the mono tests are crashing because it can’t find some runtime files and your first commit was green.
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.
Something still isn't right. libcoreclr is ending up in lib.
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.
Actually.... I ran the builds before the adjustments, and checked the previous lib-runtime-pack
folders. It turns out libcoreclr.dylib
was being placed into lib-runtime-packs/runtimes/<rid>/lib/netcoreapp5.0/
when the build was all green too. I didn't catch it prior. Checking right now if mobile also includes that. Mobile didn't include it so it's something from the first 3 commits.
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.
I think the whole ReferenceLocalCopyPaths
clearing caused the problem. I threw up a commit where we BinPlace the native libs + runtime into testhost. That basically piggybacks off of what we already have done.
636b4b0
to
8cecd66
Compare
I think this: #35295 (comment) might help you fix the test errors. Sorry for misleading in the first suggestion 😄 |
…runtime-packs This reverts commit 8cecd66.
…ntime into mdhwang/runtime_pack_all_mono
@@ -102,6 +102,12 @@ | |||
<RuntimePath>$(NETCoreAppRuntimePackNativePath)</RuntimePath> | |||
<ItemName>NativeBinPlaceItem</ItemName> | |||
</BinPlaceTargetFrameworks> | |||
<!-- Corresponding libMono and system.native libraries are added to testhost shared framework --> |
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.
@mdh1418 @steveisok I guess this is a workaround until we get the self contained test runs story for Xamarin tests, right?
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.
Yes. It will go away
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.
Awesome.
@@ -24,6 +24,10 @@ | |||
<BinPlaceItem Condition="'$(BinPlaceTestRuntimePack)' != 'true'" Include="@(NativeBinPlaceItem)" /> | |||
<FileWrites Include="@(NativeBinPlaceItem)" /> | |||
</ItemGroup> | |||
<ItemGroup Condition="'$(BinPlaceTestRuntimePack)' == 'true' and '$(TargetsMobile)' != 'true'"> | |||
<TestHostBinPlaceItem Include="%(NativeBinPlaceItem.Identity)" /> |
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.
Is this necessary? I think we can achieve the same by updating the condition to include into BinPlaceItem
. Something like: '$(BinPlaceTestRuntimePack)' != 'true' or '$(TargetsMobile)' != '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.
For my understanding ;-)
Can you give an example of what you think will work?
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.
Instead of adding this new item I think you can just update the above Item to:
<TestHostBinPlaceItem Include="%(NativeBinPlaceItem.Identity)" /> | |
<BinPlaceItem Condition="'$(BinPlaceTestRuntimePack)' != 'true' or '$(TargetsMobile)' != 'true'" Include="@(NativeBinPlaceItem)" /> | |
<FileWrites Include="@(NativeBinPlaceItem)" /> | |
</ItemGroup> |
BinPlaceItem should always contribute to the testhost directory. BinPlaceTestRuntimePack
will only be true when RuntimeFlavor == Mono
, if TargetsMobile != true
that means we're building for Xamarin Desktop. Is my assumption right?
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.
Changing the code to
<Target Name="GetBinPlaceItems">
<ItemGroup>
<NativeBinPlaceItem Include="$(NativeBinDir)*.dll" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.pdb" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.lib" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.a" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.bc" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.so" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.dbg" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.dylib" />
<NativeBinPlaceItem Include="$(NativeBinDir)*.dwarf" />
<BinPlaceItem Condition="'$(BinPlaceTestRuntimePack)' != 'true' or '$(TargetsMobile)' != 'true'" Include="@(NativeBinPlaceItem)" />
<FileWrites Include="@(NativeBinPlaceItem)" />
</ItemGroup>
</Target>
The two testhost, before and after, are identical. However lib-runtime-packs seem to differ, where the one with this change has more files.
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Globalization.Native.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Globalization.Native.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Globalization.Native.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Compression.Native.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Compression.Native.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Compression.Native.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Ports.Native.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Ports.Native.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.IO.Ports.Native.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Native.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Native.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Native.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Net.Security.Native.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Net.Security.Native.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Net.Security.Native.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.Apple.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.Apple.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.Apple.dylib.dwarf
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.OpenSsl.a
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.OpenSsl.dylib
Only in lib-runtime-packs/runtimes/osx-x64/lib/netcoreapp5.0: libSystem.Security.Cryptography.Native.OpenSsl.dylib.dwarf
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.
I can run it again, but is this desired?
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.
@steveisok we want the Xamarin Desktop runtime packs to have the native assets produced from libraries, right?
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.
Actually that's wrong. Because it is going under lib
. This is not desired. Thanks for checking @mdh1418 -- then we can't use my suggestion here 😄
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.
I answered previously assuming your question. The desktop structure for lib-runtime-packs
should mirror mobile. Libs contain the assemblies and native contains the native assets (mono runtime + system.native + SPC).
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.
Right. My suggestion here unfortunately doesn't work 😄. Whenever we start producing self contained assets I guess we can revisit and see if there is a better way.
Fixes #35247
This PR makes a small change to generate our in-tree runtime packs for all of mono, not just iOS, Android, and tvOS.
This PR will be updated and merged after #35105 is merged.Rebased ✔️After the change,
lib-runtime-packs
is generated in<runtime-repo>/artifacts/bin/
when running./build.sh -subset mono+libs
Running
./build.sh -subset mono+libs -test -c Release
after the change leads to no build errors.When building for Mono, not mobile (e.g.
./build.sh -subset mono+libs
)We want
testhost
to be generated under<runtime-root>/artifacts/bin
, yet to omit those files fromlib-runtime-packs
.After these changes, these 7 files are omitted from
lib-runtime-packs