-
Notifications
You must be signed in to change notification settings - Fork 516
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
[msbuild/dotnet] Rework how we collect and process native references. #17554
[msbuild/dotnet] Rework how we collect and process native references. #17554
Conversation
|
This comment has been minimized.
This comment has been minimized.
0805a26
to
a69abc4
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Previously, we'd do this: * Collect all possible native references. * Extract any compressed native references (*.framework.zip, *.xcframework.zip, *.resources.zip) to disk. * Resolve the resulting native references. This doesn't work very well on Windows (in non-connected/Hot Restart mode), because some compressed files may contain symlinks (in particular compressed xcframeworks). If those symlinks are for any other platform than the one we're building for, they shouldn't matter, but if we extract the entire compressed xcframework before figuring out what we need from it, we'd run into symlinks and not knowing whether they should be ignored or not. So rework the process to: * Collect all possible native references. * Resolve the resulting native references, peeking into zip files if need be. * Extract any compressed native references, but only the parts of the zip we need. This way we won't run into any symlinks unless we really need them, and it should also improve build performance slightly, even on macOS, since we're not extracting files we won't need (which can be significant for xcframeworks). Additionally: * Add support for unzipping on Windows by using System.IO.Compression. * Show an error if attempting to extract a symlink in the last step in the reworked process on Windows. * Some tests had to be updated (since they poked into internals of the ResolveNativeReferences task, and those internals have changed).
6b29806
to
9a63ef6
Compare
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
||
#nullable enable | ||
|
||
namespace Xamarin.MacDev.Tasks { | ||
|
||
// We can get numerous types of native references: | ||
// | ||
// *.dylib |
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: comment indentation
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.
@emaf fixed!
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)✅ Generator diffGenerator diff is empty Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻✅ All tests on macOS M1 - Mac Ventura (13.0) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11.5) passed. Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 225 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. [attempt 2] Html Report (VSDrops) Download Pipeline on Agent |
bool rv; | ||
if (Environment.OSVersion.Platform == PlatformID.Win32NT) { | ||
rv = TryDecompressUsingSystemIOCompression (log, zip, resource, decompressionDir); | ||
} else if (!string.IsNullOrEmpty (Environment.GetEnvironmentVariable ("XAMARIN_USE_SYSTEM_IO_COMPRESSION"))) { |
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.
Shouldn't this be part of the previous if statement using an or
operator instead of in an else if
statement since both execute the exact same line?
if (entryPath.Length == 0) | ||
continue; | ||
|
||
if (entryPath.StartsWith (resourceAsDir, StringComparison.Ordinal)) { |
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.
Similar question here, is it written in this way instead of using a single if statement to make it easier to read?
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, they're both written this way to make them easier to read.
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.
❤️
Previously, we'd do this:
*.resources.zip) to disk.
This doesn't work very well on Windows (in non-connected/Hot Restart mode),
because some compressed files may contain symlinks (in particular compressed
xcframeworks). If those symlinks are for any other platform than the one we're
building for, they shouldn't matter, but if we extract the entire compressed
xcframework before figuring out what we need from it, we'd run into symlinks
and not knowing whether they should be ignored or not.
So rework the process to:
This way we won't run into any symlinks unless we really need them, and it
should also improve build performance slightly, even on macOS, since we're not
extracting files we won't need (which can be significant for xcframeworks).
Additionally:
reworked process on Windows.
ResolveNativeReferences task, and those internals have changed).