* Don't load maccore/mk/versions.mk anymore, which means we're not checking
any subsequent dependencies listed in maccore. Note that we still need the
maccore dependency itself for a little while longer.
* Remove some outdated testing code that called into maccore.
* Don't recurse into the maccore directory during make.
* Remove some code checking for ENABLE_XAMARIN that's not used anymore, in
particular in xharness.
This makes it not necessary to check for the currently selected Xcode in our
system dependency check. It also means it'll become much easier to work with
multiple branches simultaneously where each branch needs its own Xcode.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Remove our dependency on Visual Studio. Use the 'dotnet-t4' tool instead of
invoking the t4 tool embedded in Visual Studio.
Fixes this build error after installing VS Mac 2022:
> Cannot open assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe': No such file or directory.
Adjust our versioning scheme so that the NuGet version is
`Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish
version>") causes problems on branches producing stable builds, because each
new commit would end up with the same NuGet version, and we wouldn't be able
to push those to a NuGet feed because there might already be an existing
version there.
By using the commit distance in the NuGet version we ensure that every commit
has a different version.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
Special paths are protected by the OS. This paths are problematic
becasue the xpcproxy_sim might not have access to them, resulting in the
simulator tests failing (the process cannot return the PID used to
launch the app).
The problem with special folders.. is that they could be or not
translated or changed so we cannot hardcode them, yet we can use a small
apple script to return the path of the ones we know about (documents,
downloads, etc), get them and check if pwd is a substring.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
Avoid this warning when checking for required tools/dependencies
```
You should have exactly CoreSimulator.framework version 732.18 (found 732.18
732.18). Execute './system-dependencies.sh --provision-xcode' to install the expected version.
```
Right version, but found two times ?
Because we're looking at a (now) fat framework so we get things twice
```
lipo -info /Library/Developer/PrivateFrameworks/CoreSimulator.framework/Versions/A/CoreSimulator
Architectures in the fat file: /Library/Developer/PrivateFrameworks/CoreSimulator.framework/Versions/A/CoreSimulator are: x86_64 arm64e
```
Solution ? make it uniq
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* [system-dependencies] Only use the locally installed .NET version.
We'll soon need to install files into the dotnet directory, and we don't want
to do that to the system dotnet. So just always use a locally installed .NET.
* Rework to not treat .NET 5 as an optional/installable dependency, instead download it always (like the mono archive).
This way no manual action is necessary to get it when needed, it will be
downloaded automatically.
Create the various NuGet packages to support .NET 5+. The packages are
currently empty (and not very useful), but the actual content will come later.
The current set of NuGet packages are (this list is duplicated for each
platform: iOS, tvOS, watchOS and macOS):
* Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an
MSBuild Project SDK. Will eventually contain all the build logic. Might also
eventually contain other tools (mlaunch, bgen, etc.), but these might also
end up in a different package.
* Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly.
* Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files
(libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.):
The NuGets built on CI are automatically published to a NuGet feed.
The versioning for the NuGet packages required a few changes: OS bumps are now
changed in Make.versions instead of Make.config (this is explained in the
files themselves as well).
* [system-dependencies] Add support for provisioning .NET 5 separately.
Add support for provisioning .NET 5 separately, and by default install it
locally (into builds/downloads) to avoid consuming a lot of disk space with
the various preview versions we'll need. A system install is still detected
and used if available.
* Use full path to the dotnet binary, since it might not be in PATH.
* [jenkins] Clean first, then provision.
Otherwise we'll clean whatever we provision locally.
This hack was introduced because some branches was using broken logic; all
branches we care about are now using the correct logic (it's been fixed for
over 18 months), so we can remove the hack.
* [configure] Add --[enable|disable]-dotnet.
And make it enabled by default on CI and disabled by default elsewhere for now
(because it makes the build significantly slower).
* [system-dependencies] Add support for provisioning .NET.
Also write a global.json in the root directory which is how we select which
.NET version to use.
* Bump for Xcode 11.3 beta 1
* [system-dependencies] Make it clearer what failed on the bots.
Locally we use colors to distinguish between warnings and failures, but colors
don't show up on the bots, so use text instead.
* Verbose provisioning.
* [system-dependencies] Improve simulator checks a bit.
* Non-verbose provisioning.
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.
Archive Utility compresses into a directory specified by one of its
preferences, so we can't really say for sure where it will put the extracted
xip.
This is of course all sorts of fun, except none of the good ones.
So use the command-line xip utility to extract the xip instead, which is
documented to extract into the current directory.
The reason we didn't use the 'xip' tool from the beginning is that when Apple first started shipping Xcode as xips, the --expand option wasn't documented.
Xcode 11 beta 1 ships with files that point into the system:
ls -la /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/Network.framework
lrwxr-xr-x 1 rolf staff 44 Jun 11 15:06 /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/Network.framework -> /System/Library/Frameworks/Network.framework
this means that 'xattr' will fail, since it will try to process system files,
and even if using sudo it will fail (due to System Integrity Protection):
[...]
Removing any com.apple.quarantine attributes from the installed Xcode
xattr: [Errno 1] Operation not permitted: '/Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/Network.framework'
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthRecordServices.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthRecordServices.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthMenstrualCycles.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthMenstrualCycles.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthDiagnosticExtensionCore.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthDiagnosticExtensionCore.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthDaemon.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthDaemon.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthMenstrualCyclesDaemon.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/HealthMenstrualCyclesDaemon.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/HealthKit.framework/Resources
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/HealthKit.framework/Versions/Current
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/AppleTVOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/HealthKit.framework/Modules
xattr: [Errno 1] Operation not permitted: '/Applications/Xcode11-beta1.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/Network.framework'
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/PrivateFrameworks/BookmarkDAV.framework/Frameworks
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/include/python3.7m
xattr: No such file: /Applications/Xcode11-beta1.app/Contents/SharedFrameworks/SceneKit.framework/XPCServices
Some of these failures are also due to symlinks pointing to nowhere.
Either case should be fixed by passing '-s' to xattr, which will make xattr
not follow symlinks, and instead act upon the symlink itself (which is the
right behavior in this case anyway).
* We must bump the min simulator versions, since Apple has bumped what they offer.
* Re-enable simulator provisioning.
* Minor output fix to siminstaller to make the output easier to understand.
The device tests would often fail on bots with the following:
```
Extracting /tmp/x-provisioning/Xcode_10.2.xip...
Archive Utility[4964:12156830] Persistent UI failed to open file file:///Users/xamarinqa/Library/Saved%20Application%20State/com.apple.archiveutility.savedState/window_2.data: No such file or directory (2)
Installing Xcode 10.2 to /Applications/Xcode102.app...
mv: rename Xcode.app to /Applications/Xcode102.app: Not a directory
```
This is because we might have an Xcode symlink already at the destination location. The simple fix is to always make sure the destination is clean before moving the extracted Xcode to it.
This is more future-proof, since the list of packages may change, or there may
be other tasks that need doing in addition to installing packages.
Fixes https://github.com/xamarin/maccore/issues/952.
This is a backport of the PRs #4662 and #4681.
This is more future-proof, since the list of packages may change, or there may
be other tasks that need doing in addition to installing packages.
This might help/fix https://github.com/xamarin/maccore/issues/952.
* Bump to use Xcode 10 beta 1
* Update Versions.plist
* Add a dependency on Xcode 9.4.
* [msbuild] Fix build with Xcode 10 beta 1. (#4182)
Many years ago (in Xcode 7 according to code comment)
Developer/Platforms/iPhoneOS.platform/Developer/usr disappeared, and we coped
by looking at Developer/usr instead (and also the subsequent code to locate
the bin directory was based on the location of the usr directory).
Developer/Platforms/iPhoneOS.platform/Developer/usr reappeared in Xcode 10
beta 1, but it seems useless (for one it doesn't contain a bin directory), so
in order to try to keep things sane don't look for this directory in Xcode 10
and instead go directly for Developer/usr (which is what we've been using as
the usr directory for years anyway).
Fixes this problem when building apps with Xcode 10 beta 1:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(626,3): error : Could not locate SDK bin directory [/Users/rolf/Projects/TestApp/test-app.csproj]
* [runtime] Build 32-bit mac executables using Xcode 9.4.
* [mtouch] Work around broken tvOS headers in Xcode 10 beta 1.
* [mtouch] Work around build problem with Apple's simd headers in Objective-C++ mode.
* Use version-agnostic paths to sdk directories.
* [tests][xtro] Add todo files (from unclassified) and adjust ignore files to avoid errors
* [macos][security] Re-enable SSL[Get|Set]AlpnProtocols. Fixes#4001 (#4022)
* [macos][security] Re-enable SSL[Get}Set]AlpnProtocols. Fixes#4001
This was fixed in macOS 10.13.4
https://github.com/xamarin/xamarin-macios/issues/4001
* [tests][monotouch-tests] Disable a few test cases (one crasher, other failures). Causes to be verified later
* [xharness] Fix permission dialog suppression in Xcode 10.
* [xharness] Ignore 32-bit macOS tests by default.
* [tests] Execute mmp regression tests with Xcode 9.4 since many of them are 32-bit and needs porting to 64-bit.
* [mmptest] Ignore 32-bit XM tests if we don't have a 32-bit-capable Xcode.
* [registrar] Add workaround for broken headers in Xcode 10 beta 1 (radar 40824697).
* [mtouch] Restrict another workaround for an Xcode 10 beta 1 bug to a specific Xcode version to remove it asap.
* [tests] Fix some protocol changes (public or not) find by introspection tests
* [tests][intro] Fix DefaultCtorAllowed failures
* [Intents] Obsolete several Intents classes in watchOS.
Several existing Intents classes have been marked as unavailable in watchOS in
the headers in Xcode 10 beta 1, and corresponding tests are now failing.
So obsolete the managed wrapper types, and fix tests accordingly.
* Fix xtro wrt previous Ietents/intro changes
* [tests] Minor adjustments to mtouch tests to work with Xcode 10.
* [msbuild] Update tests to cope with additional files produced by the Core ML compiler.
* [msbuild] Xcode 10 doesn't support building watchOS 1 apps, so show a clear error message explaining it.
Also update tests accordingly.
* [coreimage] Stub new filters and exclude ?removed? ones from tests
* Update GameplayKit and SpriteKit NSSecureCoding _upgrade_ and fix other non-public cases (in tests)
* [tests] Ignore some GameKit selectors that don't respond anymore (but seems to be available, at least in header files)
* [tests] Fix intro 32bits testing for filters resutls
* [msbuild] Slightly change error message to be better English.
This will add Objective Sharpie as an optional dependency, only enforced if
actually trying to run the xtro tests.
The wrench/jenkins tests will show up as green for now (since there are known
failures in the xtro tests that have to be addressed first).