Recursively printing diagnostics can leave us with _many_ lldb processes, each
pretty much hanging, and the system overloaded, which, in the worst case
scenario, would require a hard reboot.
Most commonly the "only" thing that happens is an OutOfMemoryException when
the OS eventually tells xharness NO to launching new processes.
Fixes https://github.com/xamarin/maccore/issues/1163.
Cloning directories is *much* faster than copying, so make sure we clone when
possible.
This will still fall back to copying if it the file system doesn't support
cloning.
Fixesxamarin/xamarin-macios#4107
We currently generate invalid registrar code when we get invalid input
in 'Adopts' attribute, this can happen because 'Adopts' can take a
plain string. We now generate a better error MT4177 instead of
generating invalid registrar.m/h code.
That way the report is still available even if xharness dies.
Also improve report generation to write directly to a temporary file on disk,
instead of writing to memory and then writing to disk (improves memory usage).
Otherwise we can run into cases where make things it needs to generate the
bindings, but they're identical to the previous bindings, thus nothing is
written to disk, the filestamp doesn't change, and at the next build make
continues to believe that the bindings have to be regenerated:
$ make
GEN bindings-generated.m
$ make
GEN bindings-generated.m
[ad infinitum]
The previous default (Wifi) would never work; only Http mode works on watchOS
devices. This means that unless debugging was explicitly disabled (for
instance when running without debugging from the IDE), we'd try to connect in
WiFi mode (and gracefully fail, but showing error messages that are
unnecessary and potentally scary/confusing).
This makes it possible to build mmp (the partial static registrar code) with
the wrong system Xcode (which is not supported, but that doesn't mean we can't
try to make it mostly work to ease our lives).
I tried this in the xcode9 branch (PR #2588), and it didn't stick after the
xcode9 branch was merged to master.
I tried again a year later with the xcode10 branch (PR #4691), and once again
the commit didn't stick after the xcode10 branch was merged to master.
So now I'm trying to get this directly into master instead.
Let's see if it's still there when we branch for xcode11 next year...
* [Xharness] Add a workaround to not build the xunit tests when not needed.
This is a workaround that does not use reflection to build the bcl test
projects. We need this until we have complete support of using mono as
an SDK.
* Fix mac classic build
* Fix mac 32 bits (can't load 64bits only libraries)
* Check paths too leading to fixes to old (now incorrect) paths and typo
* apitest (Mac) has a similar test - but assumed that a file that did not exists was fine (missing typos and changes);
* tvOS simulator does not (unlike iOS) support loading the MetalPerformanceShaders.framework
reference: https://github.com/xamarin/xamarin-macios/issues/5047
* [jenkins] Don't execute the packaged XM tests on the main macOS version.
Don't execute the packaged XM tests on the main macOS version, since it's redundant.
It also prevents a potential test deadlock if all main bots are busy.
* Rework to make it show better in the Jenkins UI.
* [runtime] Clean up public symbols. Fixes#5124.
Clean up public symbols, by:
* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
handle in the test.
This minimizes the chance of getting into a symbol clash with another native library.
Fixes https://github.com/xamarin/xamarin-macios/issues/5124.
* Some test fixes.
* Bump maccore to get fix for test-docs.
Commit list for xamarin/maccore:
* xamarin/maccore@6e9b63e537 Merge pull request #1162 from rolfbjarne/docfixer-fixes
* xamarin/maccore@4cf1d63b7b [docfixer] Create project files and fix a few issues. Fixes#1118.
* xamarin/maccore@714bd73a55 [docfixer] Avoid declaring the same target twice.
* xamarin/maccore@34f4bfa339 [populate] Directories need to call Directory.Exists for existence checks.
* xamarin/maccore@341333db88 [docs] Remove truly ancient and outdated targets to publish updated docs.
Diff: 7ba9c5a962...6e9b63e537
* [jenkins] Make it possible to force docs testing by applying a label to pull requests.
* [Harness] Reduce the noise in the make files.
The Makefile.cs code generates a lot of noise becuase it tries to build
a make rule for the new BCL tests, these rules do not work and can be
ignored.
Fixes issue: https://github.com/xamarin/maccore/issues/1156
* Use a full path to xibuild.
Use a full path to xibuild everywhere, since it's easier than making sure PATH
is correct every time we want to invoke xibuild.
Also remove the xbuild-in-place script, it's not used anymore.
* Fix xibuild path lookup.
* [xammac_tests] Remove unneeded csproj changes.
Only build the BCL tests when we need them, because we can't build them when
we're running the device tests (because we don't have a built source tree in
that case).
Since the test assemblies are required when generating the BCL projects, this
means we also delay creating the BCL projects until we need them.
The problem is that AppBundleDir never gets defined for library projects.
Luckily, _AppBundleName and AppBundleExtension are always defined and
all we need is the directory name (i.e. MyApp.app), so this will work
just fine.
Fixes issue #5129
`QLThumbnailReply` and `QLFileThumbnailRequest` members are called
from a background thread within `QLThumbnailProvider` extension
so our check on `UIApplication.EnsureUIThread ()` is not needed.
Fixesxamarin/xamarin-macios#5117
* xibuild: New wrapper tool to run msbuild or managed executables
MSBuild supports fallback paths for projects imported using
`$(MSBuildExtensionsPath)`, but these must be specified explicitly in
the app.config of the main executable. There was a PR to allow use of
properties for this in the app.config, but that was not accepted
upstream.
This is required for being able to:
1. build projects with msbuild against the in-tree XI/XM build output
2. and to run nunit tests against the same.
For this we introduce a new tool, `xibuild`, based on XA's `xabuild`.
This supports the fallback paths to be specified via the environment variable
`MSBuildExtensionsPathFallbackPathsOverride`[1].
It essentially operates in 3 modes:
1. `xibuild -c /path/to/foo.exe`
Generates /path/to/foo.exe.config with the fallback paths inserted into that.
2. `xibuild -- /v:diag /path/to/project.csproj`
Runs msbuild with the arguments after `--` with a custom app.config based on
`MSBuild.dll.config`, with the fallback paths correctly inserted.
This is in a temporary file and the original config file is not touched.
3. `xibuild -t -- /path/to/managed_tool.exe args`
Generates `/path/to/managed_tool.exe.config` based on `MSBuild.dll.config` with
the fallback paths inserted, and runs `managed_tool.exe` with the arguments.
The default is to overwrite the config file.
But there is also a switch to merge it with an existing config file.
--
1. Value of the environment variable $MSBuildExtensionsPathFallbackPathsOverride
is prepended to any existing list of search paths in `MSBuild.dll.config`, IOW,
it takes precedence. So, the order of lookup becomes:
- Value of the property `$(MSBuildExtensionsPath)`
- Value of the environment variable `$MSBuildExtensionsPathFallbackPathsOverride`
- /Library/Frameworks/Mono.framework/External/xbuild on macOS
* Integrate use of `xibuild` with the tests
Update all uses of `msbuild` and invocations of tools like nunit that
might depend on using the in-tree builds to use `xibuild`.
* xibuild: Move help descriptions to OptionSet itself.
Mono know provides a set of testing assemblies that contain the tests to be ran in each of the supported platforms. This commit adds the following:
1. Two different runners that can be used to execute NUnit and xUnit tests.
2. The necessary glue to get xharness to run the new tests and report the results.
3. A new test that will ensure that if mono adds new tests, xharness will report failures if the tests are not run or not ignored.
Rolf Bjarne Kvinge
Alex Soto
Sebastien Pouliot
Manuel de la Pena
Aaron Bockover
Chris Hamons
Bernhard Urban
Jeffrey Stedfast
Ankit Jain