This works around a build problem that occurs because NUnit ships with a
P/Invoke to a function that doesn't exist on Apple platforms:
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetVersionEx. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
MTOUCH : error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -fembed-bitcode-marker [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
clang : error : linker command failed with exit code 1 (use -v to see invocation) [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
Also fix an issue in mtouch where we would overwrite any previous --dlsym
values; they're now accumulative (`--dlsym:foo.dll --dlsym:bar.dll` works
as expected)
Ref: https://github.com/nunit/nunit/issues/3618
* Touch.Client references the official NUnitLite package, which means we're using
a non-forked version of NUnit.
* This makes it easier for our .NET 5 effort, since we won't have to port an ancient
version of NUnitLite to .NET 5 (nor will we have to keep using it in our existing
code, we can use more modern NUnit patterns).
* Reference MonoTouch.Dialog from the NuGet package. This also eases the .NET 5 effort,
since we won't have to port MonoTouch.Dialog to .NET 5 (we'll probably still do it
though at some point, but it doesn't have to be done right away), nor build it
ourselves / ship it.
It's running into different behavior between OS versions, and it's getting
time-consuming and annoying to keep up with the changes.
So instead just remove the test, because as far as I can see it's not testing
something important anyway (we don't care exactly which library provides the
'mono_native_initialize' function, the important part is that it's callable,
which we already test elsewhere).
Xcode 11 doesn't support anything below iOS 7.0 (the linker will automatically
change the deployment target to 7.0), so we need to drop support as well
(since our native bits will be targetting iOS 7.0, and we can't change that).
https://github.com/xamarin/xamarin-macios/issues/6213
Harness.AutoConfigureMac now loads all the mac test projects both when
configuring and running tests, the only difference is that the test projects
that must be generated are only generated when configuring. This means that
the Harness.MacTestProject list contains the exact same test projects both
when configuring and when running tests.
This made it possible to remove logic to clone (mac) test projects the Jenkins
class (since Harness.MacTestProjects contains all the test projects already).
Consolidate logic to generate (mac) test projects:
* First we generate BCL and mono-native projects from their templates.
* Then we generate Full/System variations of any project that needs it.
This way we can remove logic to generate Full/System variations from the logic
to generate BCL/mono-native projects, which means less duplicated (and less
confusing) code.
To this purpose, significant changes were required:
* MacTestProject.TargetFrameworkFlavor has been modified to contain a bit mask
of the variations to generate.
* MacMonoNativeInfo has been significantly simplified, and some of the
generated code has been moved to the actual template instead.
* Some project generation (in MacTarget) to make things work as expected.
Fixes https://github.com/xamarin/xamarin-macios/issues/6322.
* [tests] Remove 32-bit Xamarin.Mac tests (both Classic and Unified).
We're removing support for 32-bit Xamarin.Mac apps (#6300), which means we
don't need to run the tests anymore.
This part of the implementation for #6300, I'm starting with the tests because
some of our XM/Classic tests are failing and making the bots unnecessarily red
(since we'll remove XM/Classic support anyway). Also CI will be faster if we
don't run these tests.
* [mmptest] Fix build.
* [tests] Fix build for mono-native-mac.csproj.
Fixes this when running on tvOS using dylibs:
> [FAIL] Introspection.CheckSymbols : dlsym() not found mono_native_initialize()
Now:
* If on iOS, we'll always have the `mono_native_initialize` symbol, because the symbol is used in P/Invoke in a user assembly (the test assembly itself), and mtouch will make the AOT-compiled code use dlsym for P/Invokes in user assemblies (and when using dlsym we can't (native) strip away the symbol).
* If on watchOS or tvOS, we'll have the symbol when we're loading `mono_native_initialize` from a dylib. If loading `mono_native_initialize` from a static library, we can (native) strip away the symbol because mtouch will make the AOT-compiled P/Invoke use a static reference to the native symbol, and thus the `mono_native_initialize` symbol will not be present in the executable.
Rolf Bjarne Kvinge
Sebastien Pouliot
Alexander Köplinger
Martin Baulig