-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[mono][ios] Drop marshal-ilgen from iOS builds if it is not needed #88903
Conversation
…orrect order relative to building the native runtime.
src/mono/sample/iOS/Program.cs
Outdated
private static extern void ios_set_text(string value); | ||
unsafe private static extern void ios_set_text(byte* value); | ||
//private static extern void ios_set_text(string value); |
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.
Could we have these under an #if LIGHTWEIGHT_MARSHALLER
preprocessor directive, which can be controlled from the sample project file via:
<DefineConstants Condition="'$(UseLightweightMarshallingFriendlyCode)' == 'true'">LIGHTWEIGHT_MARSHALLER;$(DefineConstants)</DefineConstants>
This way the sample can still be testable for both implementations (full and lightweight) by specifying -p:UseLightweightMarshallingFriendlyCode=true
during build.
NOTE: Maybe the naming I used is not the best
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.
This is certainly doable, however I think the point is that the inclusion (or not) of marhsal-ilgen
should be automatic. So whenever someone tests code in HelloWorld which requires it, it should kick in by by itself. However it could be a good idea to have a test which marshals something nonblittable to check whether the marshaller is correctly included.
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.
Maybe we can have such test(s) in the: https://github.com/dotnet/runtime/tree/main/src/tests/FunctionalTests
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.
The scenario appears to be covered already, this test https://github.com/dotnet/runtime/blob/main/src/tests/FunctionalTests/iOS/Simulator/AOT-LLVM/Program.cs should fail if the marshaller is not properly included.
<ItemGroup Condition="'@(MonoLightweightMarshallerIncompatibleAssemblies->Count())' > 0"> | ||
<RuntimeComponents Include="marshal-ilgen" /> | ||
</ItemGroup> | ||
<ItemGroup Condition="'@(MonoLightweightMarshallerIncompatibleAssemblies->Count())' == 0"> | ||
<RuntimeComponents Remove="marshal-ilgen" /> | ||
</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.
Is there an assumption here that RuntimeComponents
is non-empty and can already include marshal-ilgen
component before reaching this target?
If yes, wouldn't we then encounter a duplication in case <RuntimeComponents Include="marshal-ilgen" />
on line 101?
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.
Oh, Include
does not check for duplicates?
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.
Unfortunately... no :)
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.
Apparently one can use KeepDuplicates
on ItemGroups. Who knew
@@ -26,6 +26,8 @@ | |||
_InitializeCommonProperties; | |||
_BeforeAppleBuild; | |||
_AppleResolveReferences; | |||
_ScanAssembliesDecideLightweightMarshaler; | |||
_ProcessRuntimeComponents; |
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.
NIT: I think _ProcessRuntimeComponents
target could be refactored a bit, especially as it has a single condition _IsLibraryMode
on an item group at https://github.com/dotnet/runtime/pull/88903/files#diff-e351a598f31c0a001f31622d9babc297dbcbe5827eabf55ab92700e1839e70f1R109
Proposed changes:
- Add a property depending on library mode builds
<PropertyGroup Condition="'$(_IsLibraryMode)' == 'true'">
<_ProcessRuntimeComponentsForLibraryMode>_ProcessRuntimeComponentsForLibraryMode</_ProcessRuntimeComponentsForLibraryMode>
</PropertyGroup>
- Adjust the
AppleBuildDependsOn
targets
<AppleBuildDependsOn>
_InitializeCommonProperties;
_BeforeAppleBuild;
_AppleResolveReferences;
_ScanAssembliesDecideLightweightMarshaler;
$(_ProcessRuntimeComponentsForLibraryMode);
_AppleAotCompile;
...
- Rename the
_ProcessRuntimeComponents
target into_ProcessRuntimeComponentsForLibraryMode
- Remove the condition on the item group on line: https://github.com/dotnet/runtime/pull/88903/files#diff-e351a598f31c0a001f31622d9babc297dbcbe5827eabf55ab92700e1839e70f1R109
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.
Updated.
/azp run runtime-maccatalyst |
No commit pushedDate could be found for PR 88903 in repo dotnet/runtime |
/azp run runtime-maccatalyst |
No commit pushedDate could be found for PR 88903 in repo dotnet/runtime |
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.
The maccatalyst failure seems related. It would be good to check the maccatalyst in sandbox environment as it uses dynamic linking.
Otherwise apart from Ivan's comments, it looks good!
Yes, both the iOS and catalyst failures are related. It seems that the analyzer correctly detects the need for |
iOS/tvOS failures could be #88909. |
/azp list |
/azp run runtime-ioslike |
Azure Pipelines successfully started running 1 pipeline(s). |
All CI failures now seem to be known issues. |
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! Thank you!
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
Addresses #88820 and contributes to #61685.
RuntimeMarshalingScanner
is used to analyze the assemblies and determine ifmarhsal-lightweight
is sufficient for them. If so, themarshal-ilgen
component is not included in the package. This should save approx. 44 KB in package size.Additionally, the iOS HelloWorld sample is fixed so that it does not require
marshal-ilgen
. This was the only assembly that needed it, from the entire application.Note: there are still some debug outputs to be removed before merging