* [xtro] Add support for Mac Catalyst. Fixes #10214.
Fixes https://github.com/xamarin/xamarin-macios/issues/10214.
* Update xtro.
* Bump Objective-Sharpie.
* Delete .todo files for frameworks we don't support.
* And another one bites the dust.
* [xtro] Update.
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.
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
- On 10.14 we were seeing unclassified issues appear that were not
on 10.13 builds.
- It turns out each instance involved a framework with a different
capitalization (PDF -> Pdf, MIDI -> Midi, WLAN -> WLan) in our bindings
than the header.
- For some reason that still isn't 100% clear, we'd see both our binding
and some clang item and register by capitalizations in the list in Log.cs
- Then we'd process the first list, write it down to disk, process the
second list (which is empty) by deleting that file that we just wrote down
* Not every old annotations have been migrated (work in progress, to be completed in another PR);
* Sanitation of the data files (e.g. removal of dupes and fixed, by Apple, entries) is done, but not automated (also a work in progress)
Even then this is immediately useful, i.e. better merged before 15.6 gets branched.
Facts:
* xtro-sharpie references Mono.Cecil 0.9.6 from a nuget.
* If a local Mono.Cecil.dll can't be found (according to the HintPath in the
csproj, which points to the nuget), then msbuild will look in the system
Mono.
* Mono 5.8 ships Mono.Cecil 0.10.
* Mono.Cecil 0.10 is not source compatible with 0.9.6 (there's a small issue
with interfaces).
* xtro-sharpie's source code works with v0.10.
This all means that xtro-sharpie will build fine as long as the 0.9.6 nuget
has *not* been restored. This can manifest itself confusingly ("msbuild xtro-
sharpie.sln" works fine from the command line, open the solution in VSfM and
it doesn't build anymore, not even from the command line, because VSfM
automatically restored nugets in the background).
Update the source code to work with Mono.Cecil 0.9.6 because there's no 0.10
nuget yet (yet keeping the code for v0.10 clearly marked as such for future
updates to v0.10).
Also bump from 0.9.6.1 to 0.9.6.4 since that's the latest available.
* [xtro-sharpie] Build with msbuild and be as quiet as requested when building.
* [xtro-sharpie] Must run as a 64-bit process, since the required native libraries are 64-bit.
* [xtro-sharpie] Add run configurations to the project file to ease debugging in the IDE.
* [xtro-sharpie] Remove xtro-plugin and the related commands.
This was needed when there wasn't a 64-bit mono, in order to run xtro-sharpie
in a 64-bit process.
Now there is a 64-bit mono, so it's not needed anymore.
Also improve makefile targets a bit, to auto-build stuff when needed, by
setting the right dependencies.
This makes us only put packages in one directory (saves disk space and time),
and it also makes project files in multiple solutions work properly
(mtouch.csproj is in tests/tests.sln and tests/mtouch/mtouch.sln).
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Chris Hamons
Sebastien Pouliot
Sebastien Pouliot
Vincent Dondain