In this case we're like iOS simulator builds: symbols may not be required under a
few circumstances, one of which is AOT compilation, which doesn't happen for catalyst
apps, thus symbols are always required for catalyst apps.
* Add a stamp file to the Mac version of _CompileToNative. This is used to
force a rebuild of the container app when an app extension changes (and was
already implemented for iOS: 8b376efa4b)
* Rename the iOS stamp file to 'bundler.stamp' instead of 'mtouch.stamp' to
ease code sharing.
* Rename the 'MmpReferencePath' and 'MTouchReferencePath' properties to
'_BundlerReferencePath' to ease code sharing.
* Merge the _GetCompileToNativeInputs targets. The only difference between iOS
and Mac (after the above changes) is that the Mac version now includes
'@(ReferencePath)' in '_CompileToNativeInput'. This should be fine as far as
I know.
This avoids some code using one value, and other code using another value.,
and things don't quite work as expected.
In particular it makes it so that passing -v to bgen makes errors show the
stack trace of the corresponding exception.
* [src] Generate a define for each framework for every platform.
Take our list of frameworks per platform, and generate a list of conditional
compiler constants that states that a framework exists for a particular
platform.
Basically generate a list of `-d:HAS_<FRAMEWORK>` for each platform.
This makes it possible to do this:
#if HAS_COREMEDIA
using CoreMedia;
#endif
instead of this:
#if (PLATFORM1 || PLATFORM2) && !PLATFORM3 || PLATFORM4 || BUT_MAYBE_IF_ITS_FRIDAY
using CoreMedia;
#endif
Which makes it much easier when adding new platforms (say Mac Catalyst), or
when a framework is added to an already existing platform.
I've included a few examples of how it would end up looking. Changing all the
code to use these new defines is not the goal (nor is it that these defines
should always be used: sometimes they make most sense, sometimes they don't).
* Use the new defines when building OpenTK-1.0.dll as well.
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
* [src] Add exception handling to generate-frameworks.csharp.
Because an unhandled exception doesn't make 'csharp' return a non-zero exit
code.
* [src] Pass -s to csharp in generate-frameworks.csharp and improve argument handling a bit.
* Pass -s to csharp so that csharp can properly distinguish script files (any
argument until -s) from normal arguments).
* Improve argument handling a bit.
* [src] Pass the output as the first argument to generate-frameworks.csharp
* [src] Use temporary file to make sure the target is rebuilt if there's a problem.
It's not necessary to have logic to compute namespaces anymore, that died with
Xamarin.iOS/Classic mode. So simplify the code to use constant values instead.
I hoped this would speed up the build a little bit, but I wasn't able to
measure any significant difference.
Currently we put the implementation assemblies for all Xamarin.iOS platforms
in the same directory. This makes it impossible to have different
implementations for the same assembly in different platforms: in particular,
we're going to want a special version of Xamarin.iOS.dll for Mac Catalyst
(that will just have type forwarders into Xamarin.MacCatalyst.dll), that that
assembly will go into the Mac Catalyst-specific directory of implementation
assemblies.
```
CreateExtendedTest: System.EntryPointNotFoundException : CGColorSpaceCreateExtended assembly:<unknown assembly> type:<unknown type> member:(null)
```
The API was added in iOS 14.0 (Xcode 12.0) but macOS 11.0 (Xcode 12.2)
and it does not exists on my Mac (10.15.7) even if I don't recall seeing
fail on the bots.
* [src] Don't generate a reference assembly for both the 32-bit and 64-bit variant of Xamarin.WatchOS.dll.
We only need one version, and in any case the code would write both the same
file, causing corruption and random build problems later.
Fixes this problem while building .NET packages:
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/dotnet/package/common.csproj(75,5): error : Classification matches no files: Xamarin.WatchOS.dll [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/dotnet/package/Microsoft.watchOS.Ref/package.csproj]
make[1]: *** [nupkgs/Microsoft.watchOS.Ref.7.1.100-ci.main.35+sha.a4a1fea86.nupkg] Error 1
* Fix the make rule too so that it doesn't claim it can generate the reference assembly.
Don't link the main executable with any dylib (except libcoreclr) on macOS,
because that may end up running library initializers in those dylibs, and they
may abort if something goes wrong.
This way we delay any failures until those dylibs are actually needed.
In particular, libSystem.Security.Cryptography.Native.OpenSsl.dylib will abort
in its library initializer if it can't find the native libssl.dylib it wants:
1d9e50cb47/src/libraries/Native/Unix/System.Security.Cryptography.Native/opensslshim.c (L122-L126)
and my system doesn't have any of the libssl.dylib versions that code wants.
* [tools] Disable Objective-C exception handling for macOS .NET apps due to a missing feature in the runtime.
We need support for dllmaps, and that isn't working on macOS yet.
* Fix to only affect .NET
Rolf Bjarne Kvinge
Manuel de la Pena
Filip Navara
Sebastien Pouliot