We're going to change the pack names to support multi-targeting, so ahead
of the pack name change I'm changing the existing logic to use a variable
for the pack name in most places (this will make the rename much easier and
simpler).
These changes should have no effect by themselves.
* [mlaunch] Fix permisisons after extracting from nuget
- A side effect of ac1fa25816 is that the permission of bin/mlaunch is no longer +x for non-root, which means it is unusable.
* Apply suggestions from code review
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Apply fix to app bundle mlaunch as well
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Download mlaunch from NuGet instead of building from maccore, and copy the
downloaded files into the packages we ship (both legacy Xamarin's pkg and .NET
nupkgs).
Eventually we'll want to reference the mlaunch NuGet from the .NET nupkgs, but
that's a later step.
Remove the following warning:
```
make[3]: warning: -jN forced in submake: disabling jobserver mode.
/Applications/Xcode_13.0.0-beta5.app/Contents/Developer/usr/bin/make -C ../../../maccore/tools/mlaunch install -j8
make[3]: warning: -jN forced in submake: disabling jobserver mode.
/Applications/Xcode_13.0.0-beta5.app/Contents/Developer/usr/bin/make
../../_build/Microsoft.iOS.Sdk/tools/bin/mlaunch
../../_build/Microsoft.tvOS.Sdk/tools/bin/mlaunch
```
There is no need to pass the number of jobs to be used to a submake
commands as per the gnu make documentation:
```
The ‘-j’ option is a special case (see Parallel Execution). If you set it to some numeric value ‘N’ and your operating system supports it (most any UNIX system will; others typically won’t), the parent make and all the sub-makes will communicate to ensure that there are only ‘N’ jobs running at the same time between them all. Note that any job that is marked recursive (see Instead of Executing Recipes) doesn’t count against the total jobs (otherwise we could get ‘N’ sub-makes running and have no slots left over for any real work!)
```
That means there is not need to pass it since it will be the default
used in submake commands. The override has not effect other the warning
and therefore is better to remove the noise.
* Add configure option to disable building for legacy Xamarin.
This can greatly speed up the debug-edit-build cycle when doing .NET
development, since it cuts down the build time in half more or less.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Diff: 0562e08b12..548fa45432
This way the bin directory doesn't unnecessarily get an updated timestamp, so
that some build targets in the dotnet/ directory don't rebuild unnecessarily.
* Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into
a separate NuGet (to avoid shipping the same mlaunch executable in three different
packages), but that can be done at a later stage.
* Add a GetMlaunchArguments task that computes the mlaunch arguments to install
or launch an app in either the simulator or on device.
* Implement the MSBuild logic to make the Run target (provided by .NET) launch
mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done
by setting the RunCommand and RunArguments properties (which the Run target uses)
to the correct values.
Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which
I haven't figured out yet:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'.
That's for a different pull request though.
Ref: https://github.com/xamarin/net6-samples/issues/35.
* [xcode12] Initial bump for Xcode 12 GM
* [tests][intro] We cannot load CoreNFC framework on iOS simulator anymore
* [tests][xtro] New Metal API are not abstract (before XAMCORE_4_0)
* [tests][intro] Fix crash when CSLocalizedString 'description' selector is called
* [tests][xtro] Add support for excluding platforms
Based on `Make.config` variables `INCLUDE_[IOS|TVOS|WATCH|MAC]`
This required moving some entries (common -> macOS) to keep the
sanitizer happy.
* [xtro] Ignore Intents watchOS differences since they will likely match iOS in the future
* Update to use Xcode 12 GMb instead of the old GM
* [tests][xtro] Remove OSLog for iOS and tvOS (changed in GM)
* [tests][msbuild] Disable FrameworkListTest based on the active/disabled platforms
* [tests][msbuild] Track new directory/file inside CoreML projects
* [mlaunch] Bump maccore and disable mlaunch if mac build is disabled
New commits in xamarin/maccore:
* xamarin/maccore@ba332d4d07 Disable mlaunch if Mac is not built (#2314)
Diff: 87a96d21c9..ba332d4d07
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Add a commit message with a pointer to the maccore hash that GitHub renders as
a link when publishing an mlaunch binary to the macios-binaries repository.
This will hopefully make it _slightly_ easier to review since verifying the
maccore hash is now just a click away.
* Put a binary copy of mlaunch in macios-binaries instead of in Azure. Fixes#3316.
If the Xamarin build is enabled, then build mlaunch from source, otherwise get it from macios-binaries.
Fixes#3316.
* Bump macios-binaries.
Commit list for xamarin/macios-binaries:
* xamarin/macios-binaries@69a9088 Bump mlaunch to xamarin/maccore@4505cd6f02 (#8)
Diff: e1e8bdf7a8...69a90882a0
* make msbuild/ after tools/.
Build msbuild/ after tools/, so that mlaunch builds when building from source,
since its build needs the MSBuild logic installed by msbuild/.
* Bump macios-binaries to get Xcode 9.3-capable mlaunch.
* Put a binary copy of mlaunch in macios-binaries instead of in Azure. Fixes#3316.
If the Xamarin build is enabled, then build mlaunch from source, otherwise get it from macios-binaries.
Fixes#3316.
* Bump macios-binaries.
Commit list for xamarin/macios-binaries:
* xamarin/macios-binaries@69a9088 Bump mlaunch to xamarin/maccore@4505cd6f02 (#8)
Diff: e1e8bdf7a8...69a90882a0
Michael Cummings (MSFT)
Rolf Bjarne Kvinge
Chris Hamons
Přemek Vysoký
Manuel de la Pena
Alex Soto