* [CoreML] Add Xcode 9 Beta 1 bindings
* Do not C# 7 here... :'(
* No C# 7 here either :'(
* Apply feedback
* [CoreML] Fix feedback and xtro
* [CoreML] Add more feedback
* Fix build.... What the heck was I thinking, always rebuild your stuff...
When we process P/Invokes to add support for exception marshaling, we may
change P/Invokes to be __Internal. This means that we need to move the check
for __Internal P/Invokes to after processing P/Invokes for exception
marshaling.
https://bugzilla.xamarin.com/show_bug.cgi?id=57833
Previously the assumption was that if an assembly not using dlsym references a
native symbol, it's not a required symbol. This is true as far as the native
linker goes: the native linker will see that the native symbol is referenced
by the AOT-compiled code, and it won't be removed.
However, we use also this exact logic to create the list of functions we ask
the native strip command to preserve, and in this case we need to include all
symbols needed in all assemblies that looks up native functions using dlsym.
https://bugzilla.xamarin.com/show_bug.cgi?id=57826
Some Quote implementations quoted backslashes, some didn't. When selecting a
common implementation, one of the implementations that didn't quote
backslashes won, and the rest were forgotten. Almost. Except for the MT0106
test, which started failing, thus exposing the winner's deficiencies.
So dethrone the implementation that won and reinstante the importance of the
backslash.
https://bugzilla.xamarin.com/show_bug.cgi?id=57768
- Fixed the generator to avoid `ARKit/ARSCNViewDelegate.g.cs(189,43): error CS0432: Alias 'Iglobal' not found`.
- ARPointCloud can be tested with this [sample](https://github.com/VincentDondain/ios-testcases/tree/master/ARPointCloudTest).
It requires deploying on devices and moving the camera around so ARKit can return some points. After 5 seconds it should print the points.
- Fixed intro tests.
- Fixed `bindings-generator.cs` for new simd types.
* [CoreNFC] Add CoreNFC Xcode 9 Beta 1 Bindings
CoreNFC is not exposed in iOS simulator, no framework/headers are found
makes sense since there is no NFC chip on it.
CoreNFC says it is available on tvOS but headers says just 3 enums
are so not enabling tvOS in this first beta.
* [mtouch] CoreNFC not available on sim, this makes mtouch aware of it
HFS normalizes filenames to Form D when files are stored. This means that an
assembly whose assembly name is stored in Form C might be stored in a file
whose filename is Form D (which you'll get if you use the Form C filename).
However, this is a problem when we've already loaded an assembly and if we
doesn't take normalization into account: we check the cache based on the
filename, but store in the cache based on the assembly name. If those two uses
different normalization schemes, bad things (bug #57266) happen.
So in these scenarios normalize strings before comparing them.
https://bugzilla.xamarin.com/show_bug.cgi?id=57266
- Update Versions-ios and Versions-mac file too.
- Bump maccore and maciostools to the xcode9 branch.
- [builds] Force disable 'futimens' and 'utimensat' so that we build with Xcode 9.
- [builds] 'system' is not available on iOS (simulator).
- [runtime] Fix: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
- Prevented building xcode9 branch, see: https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/3886/console
```
runtime.m:1122:9: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
char *last_sep = strrchr (info.dli_fname, '/');
```
- [registrar] Apple removed a header, so don't include it anymore.
- [mtouch] Don't run the partial static registrar for tvOS.
The generated output doesn't compile because Apple forgot to ship headers for
the ExternalAccessory framework in their tvOS simulator SDK.
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
In 11390f119c we stopped setting the force flag
when the cache was invalid, because we'd delete the cache anyway, and it was
determined that deleting the cache was enough.
Unfortunately it's not, because some output is not in the cache, and might not
get correctly updated.
Scenario:
* User builds app.
* User changes some build option (for instance switching off incremental
builds).
* User does an insignificant change in a source file for the executable
process.
* User builds app again (without cleaning). This will rebuild the exe, but
since the change was insignificant, all the IL, except the MVID, would
remain identical.
* mtouch would see that the command-line options changed, and invalidate the
cache. This would delete the cache, and everything would be rebuilt,
including AOT-compiling the assemblies again.
* When the time came for mtouch to copy assemblies to the app directory,
mtouch would realize that the existing .exe in the app (which was not
deleted because it's not in the cache, but the actual output directory) was
only insignificantly different (only the MVID was different, which our cache
logic knows to ignore when comparing assemblies), so it wouldn't copy the
.exe to the .app.
* At runtime we'd assert, because the MVID in the aot-compiled code was
different from the MVID in the assembly:
error: Failed to load AOT module '(null)' while running in aot-only mode: doesn't match assembly.
* The exact assert varies depending on which build option changed. Other
variations:
Failed to load AOT module '(null)' while running in aot-only mode: compiled against GC (4, while the current runtime uses GC sgen)
* Assertion at /Users/builder/data/lanes/4691/0719ced1/source/xamarin-macios/external/mono/mono/metadata/metadata.c:1118, condition `idx < t->rows' not met
Because of this I'm reverting 11390f119c, and
once again setting the force flag when the cache is invalid. It might be
overkill, but it's the safest option (cache invalidation is after all the only
hard problem in computer science), and bugs are very annoying and
timeconsuming to track down.
https://bugzilla.xamarin.com/show_bug.cgi?id=54973
This change introduces the export of create_classes methods as objc compatible, without enforcing Objective-C++ as the development language for custom registrar embedders by moving the stringbuilder flushing inside the extern "C" block.
Mark the generated linking code as extern "C" too and also change the return type of xamarin_create_classes_Xamarin_Mac to void in mmp generation, as it was mistakenly set to int.
When converting strings to a sequence of bytes, we can't just cast chars to
ints, and write that, because non-ascii characters will resulting values
outside the byte range.
Instead explicitly convert the string to a UTF8 byte array, and process that.
https://bugzilla.xamarin.com/show_bug.cgi?id=56876
Since ee4c07b9ce we treat config files like
debug files and assemblies (they're all touched after the linker is done).
This means we also need to apply the same logic when copying config files as
we do when copying debug files and assemblies (only copy if the contents are
different), otherwise we end up rebuilding too much.
This fixes a few test failures:
1. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[])
single
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:21:25 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:21:24 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory294/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:21:24 PM" >
2. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[])
dual
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:22:44 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.aotdata.arm64 is modified, timestamp: 5/29/2017 6:22:43 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:22:43 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory298/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:22:37 PM" >
3. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[])
llvm
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:23:38 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:23:37 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory302/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:23:37 PM" >
4. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[])
debug
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:24:22 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension.aotdata.armv7 is modified, timestamp: 5/29/2017 6:24:22 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory306/testServiceExtension.appex/testServiceExtension.dll.config is modified, timestamp: 5/29/2017 6:24:21 PM" >
5. Failed : Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[])
single-framework
Expected: <empty>
But was: < "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.MTouchTool.CreateTemporaryDirectory310/testServiceExtension.appex/testServiceExtension is modified, timestamp: 5/29/2017 6:25:07 PM", "/Users/builder/data/lanes/1381/a6cf8c5e/source/xamarin-
The AVFoundation framework's headers used to be broken in the simulator SDK
([1], [2]) until watchOS 3.2 (Xcode 8.3) fixed it. This means it's now safe to
use AVFoundation.
Additionally set the initial SDK version where this framework was introduced
to 3.2 for simulator builds, which means that if customers try to use it (with
an old Xcode), they will get a nice-ish error:
> MTOUCH : error MT4134: Your application is using the 'AVFoundation' framework, which isn't included in the watchOS SDK you're using to build your app (this framework was introduced in watchOS 3.2, while you're building with the watchOS 3.1 SDK.) Please select a newer SDK in your app's watchOS Build options.
instead of an ugly:
> MTOUCH : error MT4109: Failed to compile the generated registrar code. Please file a bug report at http://bugzilla.xamarin.com
the error message is slightly incorrect (the problem is only with the
simulator SDK, not the device SDK), but this should happen very rarely (it
only occurs if all of the following are true: using AVFoundation + in a
simulator build * the static registrar manually selected), so IMHO a more
accurate error description isn't worth it.
https://bugzilla.xamarin.com/show_bug.cgi?id=56862
[1] 7149661251
[2] https://openradar.appspot.com/29131674
* Update to mono 2017-04 branch
* Patch from Zoltan to fix build error with CppSharp.CppParser.dll
* Include new linker files in Makefile, based on mareks commit
* [msbuild] Fix running bgen for Xamarin.Mac.
bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.
* System.Data tests should act as if they are running on mobile profile
* Add --runtime=mobile to mono flags in Modern
* Move runtime launcher options up
* System.Data tests should use Mobile profile (mac fix)
* Bump 2017-04 to pick up AOT and assembly resolution fixes
* Build fixes for netstandard.dll and System.Drawing.Primitives.dll
The new handling went in with https://github.com/mono/mono/pull/4501.
I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.
* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS
* Fix 2.1/Facades/netstandard.dll build
* Fix the netstandard targets
* Bump mono to latest 2017-04 commit
* [xharness] Fix adding defines to csproj by correctly detecting existing defines.
* Bump mono to latest 2017-04 commit
* [mtouch] Update csproj with new files.
* [mtouch] Improve reporting for MarkExceptions from the linker.
* Bump mono to latest 2017-04 commit
* Bump mono to pick up latest 2017-04 branch commit (Fixes#55436)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436
* Add a missing Makefile dependency
* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time
(It is currently being applied for some configurations at runtime only)
* Bump system mono
* Bump mono for assembly loader changes
* Bump system mono
* Update assemblies list as some where moved to facades
6ca5ec442bc38e4d9220
* Bump mono to latest 2017-04 commit
* Add another new facade
* Bump mono to tip of 2017-04.
* Bump mono to tip of 2017-04.
* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes#56307 and #56308.
System.dll is now completely linked away unless the app actually uses any
System.dll API.
This is the change that caused this to change: 4960d5d2a2
Previously the following types would always be kept by the linker:
```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```
Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).
With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.
I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.
This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.
This means that the fix is to modify these tests accordingly.
https://bugzilla.xamarin.com/show_bug.cgi?id=56307https://bugzilla.xamarin.com/show_bug.cgi?id=56308
* Bump mono to latest.
* Fix merge conflict that was missed
* [mtouch] Renumber new error which clashes with an existing error number in master.
* [registrar] Add support for specifying that a protocol changed informal status in a certain SDK. Fixes#43780
Add support for specifying that an informal protocol became a formal protocol
(or the reverse) in a certain SDK version, so that the static registrar can
generate the correct code based on the SDK being built with.
This also fixes a series of compiler warnings when using the static registrar:
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:374:11: warning: duplicate protocol definition of 'CALayerDelegate' is ignored
@protocol CALayerDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:798:11: note: previous definition is here
@protocol CALayerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:824:11: warning: duplicate protocol definition of 'WebDownloadDelegate' is ignored
@protocol WebDownloadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebDownload.h:60:11: note: previous definition is here
@protocol WebDownloadDelegate <NSURLDownloadDelegate>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:851:11: warning: duplicate protocol definition of 'WebFrameLoadDelegate' is ignored
@protocol WebFrameLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebFrameLoadDelegate.h:51:11: note: previous definition is here
@protocol WebFrameLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:866:11: warning: duplicate protocol definition of 'WebPolicyDelegate' is ignored
@protocol WebPolicyDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebPolicyDelegate.h:138:11: note: previous definition is here
@protocol WebPolicyDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:869:11: warning: duplicate protocol definition of 'WebResourceLoadDelegate' is ignored
@protocol WebResourceLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebResourceLoadDelegate.h:46:11: note: previous definition is here
@protocol WebResourceLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:872:11: warning: duplicate protocol definition of 'WebUIDelegate' is ignored
@protocol WebUIDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebUIDelegate.h:153:11: note: previous definition is here
@protocol WebUIDelegate <NSObject>
^
https://bugzilla.xamarin.com/show_bug.cgi?id=43780
* [registrar] Use a string to specify when a protocol went from informal to formal.
Use a string to specify when a protocol went from informal to formal, and
don't support the reverse condition (going from formal to informal), since
it's currently not needed and makes the code more complicated and harder to
understand.
Also add an mtouch test, and update an existing mmp test to be more restrictive.
* [registrar] Rename from 'InformalUntil' to 'FormalSince'.
It just sounds better.
* [generator] Keep [NotImplemented] info so it is usable in 3rd party bindings. Fixes bug 52664
https://bugzilla.xamarin.com/show_bug.cgi?id=52664
Currently we do not keep the [NotImplemented](0) information and the
generator gets a little confused because it will not find an Export
inside the getters/setters of properties and there is no way to tell
if this was intentional or not. We now keep the [NotImplemented]
and also add some null checks in the generator where needed.
Reenabled tests disabled in 9f036b218a
[0]: https://developer.xamarin.com/guides/cross-platform/macios/binding/objective-c-libraries/#Objective-C_Mutable_Pattern_and_Properties
* [generator] Implement feedback
* Added quote method
* Teach linker about NotImplementedAttribute
* [generator] Improve Quote method
* [generator] Fix quote now for realsssss
This avoids the following compiler warning:
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:5:2: warning: gl.h and gl3.h are both included. Compiler will not invoke errors if using removed OpenGL functionality. [-W#warnings]
I found the magic symbol by looking at the headers.
* [mtouch] Allow code sharing assemblies from multiple locations if they're identical. Fixes#56498.
We disallow code sharing when the same assembly (based on name) is referenced
from multiple paths, but poke a hole in this logic by allowing the same
assembly from multiple paths when those assemblies are 100% identical, since
that should be 100% safe.
https://bugzilla.xamarin.com/show_bug.cgi?id=56498
* [tests] Comment out assert that asserts due to another bug.
* [mtouch] Don't look for assembly references in attributes in assemblies we ship. Partially fixes#49087.
Don't look for assembly references in attributes in assemblies we ship,
because it takes a significant amount of time to do this, and we can
precompute the fact that there aren't any such assembly references.
Additionally add a test to ensure we catch any changes to this assumption.
For a simple test app this makes rebuilding (without any changes) go from
~1.1s to ~0.4s.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [tests] Simplify tests to not use [TestCaseSource].
Using [TestCaseSource] is nice when running from the IDE, since it shows all
test cases in the test tree.
Unfortunately it causes the console runner to freak out [1], because the method
that lists all the test cases calls Configuration's cctor, which calls
TestContext.CurrentContext.TestDirectory, which is apparently not safe this
early in the test run.
[1] I think 'freak out' is the appropriate term for this behavior, which has
absolutely no direct nor obvious connection to the cause of the problem:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL 93a78115_c0da_4b6a_9661_9f9b9d9fb935/6669afd6_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <270c90abbc234cde9d33eb198a97cf71>:0
Fixes this compiler warning:
/work/maccore/master/xamarin-macios/tools/common/DerivedLinkContext.cs(12,28): warning CS0649: Field 'DerivedLinkContext.StaticRegistrar' is never assigned to, and will always have its default value null
and makes the mmp code closer to mtouch.
Make sure to instantiate an Assembly instance for every assembly loaded using
the cached list of assemblies.
Fixes the following test failures:
1. Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[]) : second build
Expected: 0
But was: 1
2. Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[]) : second build
Expected: 0
But was: 1
3. Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[]) : second build
Expected: 0
But was: 1
4. Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[]) : second build
Expected: 0
But was: 1
5. Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[]) : second build
Expected: 0
But was: 1
* [mtouch] Cache the list of assemblies we computed. Partially fixes#49087.
Computing the list of assemblies can be expensive, so cache it and re-use the
cached list if we can.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [mtouch] Create directory before trying to create files to it.
The generated registrar code must be built with -DDYNAMIC_MONO_RUNTIME so that
it references our local mono functions which do a dynamic function lookup.
This fixes an issue where release builds that don't embed mono fails to link,
because there are numerous unresolved externals pointing to mono symbols.
If both an extension and the container app (or multiple extensions) reference
the same binding assembly for a framework, then we'd error out with an
internal error when trying to copy the framework from both locations to the
container app.
So instead detect when we're trying to copy multiple identical (by comparing
the on-disk contents) frameworks, and only copy one of them.
We'll still show an error if the frameworks are different, but now a nice
MT1035 error with a proper error description instead of an internal error.
https://bugzilla.xamarin.com/show_bug.cgi?id=56635
[registrar] Support 'out' parameters from NULL pointers. Fixes#54919.
Native code doesn't have the 'out' and 'ref' distinction C# has, and passes
NULL around left and right.
So make sure the generated code from the static registrar doesn't write to such NULLs.
https://bugzilla.xamarin.com/show_bug.cgi?id=54919
This XM-only RemoveSelectors works on FieldDefinition but in some cases,
e.g. inside a generic types, it's FieldReference that are encoded. This
meant the static constructor was not re-written correctly and would throw
a TargetInvocationException (since the fields were removed correctly)
https://bugzilla.xamarin.com/show_bug.cgi?id=55693
`csc` without `/optimize` generates different IL, including additional
and not required load and store instructions. We previously ignored them
but that could leave the stack unbalanced leading to runtime exceptions.
We are now nop'ing the extraneous instructions (same as the rest of the
unneeded branch code)
This fixes#53872 [1] and also the known parts of #56209 (the other parts
are still NEEDINFO and could, possibly, be unrelated).
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=53872
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=56209#c2
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.
* Add XM SDK + LinkSkip test
* [macos] Add platform linking support to msbuild
* [macos] Add full SDK test
* [macios] Diable classic from using linkplatform
- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
This is because the generated output from the static registrar depends on the
managed exception marshaling mode, and the partial static registrar executes
with the default managed exception marshaling mode.
https://bugzilla.xamarin.com/show_bug.cgi?id=55870
* [mmp/mtouch/ObjCRuntime] Calculate the path to the runtime-options.plist using NSBundle's ResourcePath.
The anatomy of apps and frameworks differ between iOS and macOS:
* iOS: we put runtime-options.plist in the root directory of the app.
* macOS:
* for apps we put runtime-options in foo.app/Contents/Resources
* for frameworks we put runtime-options in foo.framework/Versions/Current/A/Resources
Luckily NSBundle's ResourcePath property returns exactly this path, so change
our logic to use this property.
Also calculate the NSBundle using an exported type we know we have (using the
main bundle won't work when we're a framework).
* [tests] Add mmp/mtouch tests to verify the default HttpClientHandler according to build arguments.
* [ObjCRuntime] Use a custom class for finding the bundle.
Use a self-defined custom class to find the bundle where our resources are.
Using the internal NSObject.NSObject_Disposer class doesn't work when this
file (RuntimeOptions.cs) is compiled into System.Net.Http.dll.
Given Xcode.app in /Applications/Xcode.app, mmp now accepts:
* --sdkroot=/Applications/Xcode.app
* --sdkroot=/Applications/Xcode.app/Contents
* --sdkroot=/Applications/Xcode.app/Contents/Developer
All were accepted in mtouch, but only the last one was previously accepted in
mmp.
It does not make sense to support incremental builds for the simulator (since
no AOT compilation is done), it just makes the test matrix more complicated.
So simplify things by removing support for incremental builds.
We also ignore any (other) --assembly-build-target arguments, because building
to frameworks doesn't make sense either in the simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=55712
The linker doesn't allow it when building for bitcode:
> ld: -ignore_optimization_hints and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
This fixes the Xamarin.MTouch.StripBitcodeFromFrameworks(tvOS,Marker) mtouch test.
This dramatically decreases the size of watchOS apps built for debug when
using frameworks, because it ends up removing all the bitcode from
Mono.framework.
https://bugzilla.xamarin.com/show_bug.cgi?id=55256
* [runtime] Fix Xamarin-debug.framework's install name.
This makes building to frameworks work in debug mode.
* [mtouch] Fix check to add frameworks to watchKit extensions.
* [mtouch] Never pass -read_only_relocs to the native linker when bitcode is enabled.
* [mtouch] Bitcode requires linking with c++.
This particular case applies to shared libraries/frameworks (we already link
with c++ when building statically).
This makes registrar.h compilable as Objective-C (as opposed to
Objective-C++), because the __monoObjectGCHandle field (whose type is an C++
type) isn't there anymore.
Of particular importance is if we're building for LLVM or not: this fixes a
bug where we wouldn't pass --llvm to the AOT compiler when compiling
assemblies to frameworks (which we do when sharing code).
https://bugzilla.xamarin.com/show_bug.cgi?id=55555
When collecting a list of roots, it helps adding any roots we find to the list
of roots.
This fixes the MT0023 mtouch tests, since now we actually report MT0023
because we have a list of the root assemblies.
* Remove the MT0008 test, since the error will never be shown again.
* Check non-existent root assemblies and report MT0018 instead of MT0007 if
they look like command-line arguments.
* Collect all MT0018/MT0007 errors before reporting any of them.
We automatically add the product assembly as a root assembly when in
embeddinator mode (because other root assemblies may not reference it), but we
don't want to mark all public types from product assemblies.
Put simulator assemblies in MonoBundle/simulator for frameworks, so that we
can have a single framework that contains both device and simulator
assemblies without assemblies conflicting between device and simulator.
The device assemblies continue in the same place, in the MonoBundle directory,
so no additional checks are needed on device.
When in embeddinator mode, we must link the generated registrar and pinvoke
code into the framework we create.
This also requires creating the corresponding aot/link tasks after creating
the registrar/pinvoke tasks.
When gathering frameworks, gather into the product assembly's frameworks, not
the global frameworks.
This is necessary when building a non-linked dylib/framework in embeddor mode,
because we link the registrar code into the framework, and that code will
require linking with all the frameworks all the assemblies require.
Also stop using `mdb` as the name for debug symbols and remove
> static MdbReader mdb_reader;
since we're not mkbundl'ing mtouch anymore.
Related to https://github.com/xamarin/xamarin-macios/pull/2002 for mmp
* [mtouch] Only iOS has version 8 (and earlier OS versions that don't support frameworks).
* [mtouch] Update logging to be less confusing when logging about WatchKit extensions.
* [mtouch] Don't compile P/Invoke wrappers for extensions that are sharing code.
The container app already has the P/Invoke wrappers.
* Use Visual Studio instead of Xamarin Studio.
* VS doesn't have mdtool, it has vstool.
Also there's no need to manually invoke the mdtool.exe executable anymore
(which we did because the mdtool executable had a min macOS version of 10.9,
and we used to build tests on older macOS versions [1]), since now we only run
tests on older macOS versions, we don't build those tests there.
[1] a1932b0ccd
We want to copy the aot data for both the 32-bit and the 64-bit versions of an
assembly even if the 32-bit and 64-bit versions of the assembly are identical.
https://bugzilla.xamarin.com/show_bug.cgi?id=54499
- Before this mmp was not adding -framework, -weak_framework consistently on non-static registrar use cases
- GatherFrameworks was previously not ported from mtouch, and did not work as DeploymentTarget was unset in mmp
- Added verbose prints so users can determine why various framework linkages are added
- Fixed an issue where duplicate were being added due to HandleFramework shoving args by hand
- Tested with auto test and https://github.com/chamons/xm-version-regression-test manual test
Previously we copied any equivalent .dylib and ran install_name_tool on the
library to change the library id to make it a framework.
Unfortunately this does not work when the library contains bitcode, because
bitcode embeds linker flags (-install_name for instance), and
install_name_tool does not change those linker flags.
This means that we need to create frameworks by linking with the proper
arguments, since it's much more difficult to fixup the embedded bitcode linker
flags as well.
So change how be build Mono.framework, Xamarin.framework, and any frameworks
built from assemblies to:
* Always link instead of fixup a dylib. For Mono.framework this means
extracting all the object files from libmonosgen-2.0.a and linking those,
for Xamarin.framework this means linking the object files we've already
built.
* Make sure the library is correctly named when linked (once again: bitcode
contains embedded linker flags, so renaming the executable later breaks
stuff as well).
I've also extracted the logic that creates Mono.framework from
libmonosgen-2.0.a to a separate shell script, to deduplicate this logic.
This required a minor change in the mono builds: we need the Mono.framework
when building the `all` target, so make sure that happens.
https://bugzilla.xamarin.com/show_bug.cgi?id=53813
* [builds] Improve mono/llvm dependencies.
* Create a list of all the files in the mono and llvm repositories, and save
these lists as a Make variable (in a generated Makefile - .deps.*.mk). We
don't list _all_ the files in each repository, because there are quite a few
(55k for mono), and Make measurably takes a while to check all of them, so
try to limit it to a sane subset, without risking missing changes to files
that actually matters.
* Always create stamp files when we're done with mono builds.
* Modify the mono/llvm builds to depend on all the files in their
repositories.
* Explicitly list the corresponding .stamp-build-* files as dependencies for
various files that are produced by the mono builds, so that make knows how
to build these files.
* Rewrite the *-facade-check targets to depend on the corresponding
*_BCL_TARGETS, so that we can avoid running a submake to the same Makefile
to execute the facade checks.
It now takes a little while (less than a second on my machine, which is
fine) for make to list all dependencies and get their timestamps, but if
executing multiple submakes this adds up to a multi-second timewaste.
So avoid the timewaste by not doing submakes, but instead use dependencies
to enforce the required target execution ordering.
* Don't depend on nicely named intermediate targets, since won't prevent
rebuilds:
build-cross64: setup-cross64
Since the `setup-cross64` file doesn't exist, `build-cross64` will always
execute. Instead depend on the stamp file:
build-cross64: .stamp-configure-cross64
And now `build-cross64` will only rebuild if needed.
* Don't try to list all intermediate files as .SECONDARY dependencies, instead
list none at all, which works as if all files were listed as dependencies.
* Some targets had to move later in the file, since variables used in dependencies:
foo: $(VARIABLE)
must be defined before that point in the file, as opposed to variables used in recipes:
foo:
$(MAKE) $(VARIABLE)
can be defined anywhere in the Makefile.
* Simplify the targets that sign assemblies significantly.
There are a few end results:
* It's now possible to do `make install`, without doing `make all` first. This
might seem weird, but that also ensures the more common `make all install`
works properly.
* Remakes (without any mono/llvm changes) in build/ are much faster, because
we now won't recurse into every mono build:
$ time make all -C builds/ -j8
[...]
real 0m1.873s
This even means that we might be able to make it a habit to remake in the
root directory, which doesn't take forever now:
$ time make all -j8
[...]
real 0m4.521s
Unfortunately adding `make install` to the mix still does some useless
stuff, and it ends up taking ~30 seconds to complete a full build:
$ time make all install -j8
[...]
real 0m32.542s
* [msbuild] Don't verify the xml syntax of targets files unless the files change.
* [build] Don't depend on installed files.
Don't depend on installed files, because that causes a rebuild when installing
to a different directory (i.e. package creation).
* Bump maccore to get build improvements.
Rebuilds are now very fast:
$ make all install -j8
$ time make all install -j8
real 0m5.735s
Less than 6s to figure out that nothing needs to be done.
And strangely flushing the disk cache doesn't make it much slower:
$ sudo purge
$ time make all install -j8
real 0m7.309s
Which probably means that Make mostly reads file metadata, and not actual file
contents (which is good).
This fixes a file sharing exception:
> MTOUCH: error MT1009: Could not copy the assembly '[...]/msbuild/tests/MyActionExtension/bin/iPhone/Debug/MyActionExtension.dll' to '[...]/msbuild/tests/MyTabbedApplication/obj/iPhone/Debug/mtouch-cache/32/Link/MyActionExtension.dll': Sharing violation on path [...]/msbuild/tests/MyActionExtension/bin/iPhone/Debug/MyActionExtension.pdb
This should stop errors like below to happen on wrench
```
Xamarin.Bundler.MonoMacException: The type 'AVFoundation.IAVContentKeyRecipient' (used as a parameter in AVFoundation.AVContentKeySession.Add) is not available in macOS 10.12.2 (it was introduced in macOS 10.12.4). Please build with a newer macOS SDK (usually done by using the most recent version of Xcode).
```
A fix (thanks Rolf!) in how we do SDK version checks is needed
because for some reason `new Version (3, 2, 0)` isn't the same to
`new Version (3, 2)` and we end up with a MT4134 when building the
watchOS static registrar.
When using debug simulator we don't generate main.m so we were not passing the gc options.
The MONO_GC_PARAMS variable is not in app.EnvironmentVariables (which only contains environment variables passed to mtouch using --setenv), which is why the above condition does not trigger.
No frameworks should be bundled in WatchKit 1 extensions, they should be
bundled in the container (iOS) app.
This broke when merging the equivalent fix for master into the framework-sdk
branch (i.e. a broken merge).
- Update comments on XM45.targets file
- Remove unnecessary AssemblySearchPaths hack causing issues using nugets with same name as Facades
- Note: MSBuild with XM 4.5 is still broken for now
This cuts down another group of conditional compilation sections, paving the
way for an IKVM-based generator.
This makes it required to pass --target-framework for to generator executables
(previously only required for Xamarin.Mac/Unified to distinguish between the
different Xamarin.Mac/Unified variants), but it should be invisible to users
since we'll automatically pass the correct --target-framework argument from
the corresponding scripts (btouch/btv/bwatch/bmac) and the MSBuild targets.
This will only break somebody who is executing the managed executables
directly, but nobody should do that in the first place (it's not a supported
scenario).
Generated diff: https://gist.github.com/rolfbjarne/1674be6625632446dba774a305951981
Besides the obvious reasons, this is also useful when testing warnings, since
by making warnings errors, mtouch/mmp will exit a lot faster (and the tests
will finish faster).
The cached linker results can have multiple identical input assemblies (for
assemblies that show up in both the app and any app extensions), so make sure
we don't load those more than once.
Since the linker can process multiple apps/appex'es at the same time, it also
means it will put together all the required symbols found in _all_ assemblies.
This means that we need to filter out required symbols for other
apps/appex'es.
Change cache invalidation so that if any app extension's cache is invalid,
then invalidate the cache for the container app and all other app extensions.
This is the safest option when we're sharing code.
Don't use the global command line arguments to determine input, because that's
not the input we use for app extensions anymore.
Instead explicitly pass the input arguments when creating the cache.
Since neither mtouch nor mmmp is mkbundled anymore, the installed binary is in
fact a shell script.
This means that it's quite useless to check if the shell script has been
modified; instead check if the executing assembly has been modified (which
works now that we're not mkbundled anymore).
We must build each appex bundle before the container bundle, so that we can
compute the frameworks each appex the needs before bundling the container app.
Also there's no need to store the list of frameworks appex's need in a file,
since everything is now done in the same mtouch process.
Implement support for sharing both code and resources between app extensions
and their container app:
* AOT-compiled code. Each shared assembly is only AOT-compiled once, and if
the assembly is built to a framework or dynamic library, it will also only
be included once in the final app (as a framework or dynamic library in the
container app, referenced directly by the app extension). If the assemblies
are built to static objects there won't be any size improvements in the app,
but the build will be much faster, because the assemblies will only be AOT-
compiled once.
* Any resources related to managed assemblies (debug files, config files,
satellite assemblies) will be put in the container app only.
Since these improvements are significant, code sharing will be enabled by
default.
Test results
============
For an extreme test project with 7 extensions (embedded-frameworks)[1]:
with code sharing cycle 9 difference
build time 1m 47s 3m 33s -1m 46s = ~50% faster
app size 26 MB 131 MB -105 MB = ~80% smaller
For a more normal test project (MyTabbedApplication)[2] - this is a simple application with 1 extension:
with code sharing cycle 9 difference
build time 0m 44s 0m 48s -4s = ~ 8% faster
app size 23 MB 37 MB -15 MB = ~40% smaller
Another tvOS app with one extension also show similar gains (MyTVApp)[3]:
with code sharing cycle 9 difference
build time 0m 22s 0m 48s -26s = ~54% faster
app size 22 MB 62 MB -40 MB = ~65% smaller
[1]: https://github.com/rolfbjarne/embedded-frameworks
[2]: https://github.com/xamarin/xamarin-macios/tree/cycle9/msbuild/tests/MyTabbedApplication
[3]: https://github.com/xamarin/xamarin-macios/tree/cycle9/msbuild/tests/MyTVApp
Warn if mtouch loads an assembly from a different location than requested
(which might be because there are multiple assemblies with the same name).
Also rework the MT0023 check a bit by explicitly loading the root assembly
first, and then detecting if any loaded assemblies matches the root assembly.
This results in code that's a bit more obvious, and it also works correctly
with extensions (previously the entire MT0023 check was skipped for
extensions).
Allow the assembly build target name for frameworks to end with '.framework',
so that the following:
--assembly-build-target=@sdk=framework=Xamarin.Sdk.framework
doesn't end up creating Xamarin.Sdk.framework.framework.
Store the location of every assembly that can't be deduced at runtime (i.e.
all assemblies that are build to frameworks, since there can be multiple
assemblies in each framework, and the framework name can be customized).
Detect when assemblies have native dependencies between them (which can happen
when there are multiple binding projects, and the native libraries in those
binding projects have dependencies between them), and add the proper link
arguments (this is only required when building to dynamic libraries or
frameworks, since otherwise everything is linked to one big binary and there
are no dependency problems).
https://bugzilla.xamarin.com/show_bug.cgi?id=43689
The previous build system kept a forward-pointing single linked list of tasks
to execute: task X had a list of subsequent tasks to execute. If task X was
up-to-date, it was not created (and the next tasks were directly added to the
list of tasks to execute).
In this world it became complicated to merge output from tasks (for instance
if the output of task X and task Y should be a consumed by a single task
producing a single output, since the corresponding task would end up in both
X's and Y's list of subsequent tasks).
Example: creating a single framework from the aot-compiled output of multiple
assemblies.
So I've reversed the logic: now we keep track of the final output, and then
each task has a list of dependencies that must be built.
This makes it trivial to create merging tasks (for the previous example, there
could for instance be a CreateFrameworkTask, where its dependencies would be
all the corresponding AotTasks).
We also always create every task, and then each task decides when its executed
whether it should do anything or not. This makes it unnecessary to 'forward-
delete' files when creating tasks (say you have three tasks, A, B, C; B
depends on A, and C depends on B; if A's output isn't up-to-date, it has to
delete its own output if it exists, otherwise B would not detect that it would
have to re-execute, because at task *creation* time, B's input hadn't
changed).
Additionally make it based on async/await, since much of the work happens in
externel processes (and we don't need to spin up additional threads just to
run external processes). This makes us have less code run on background
threads, which makes any issues with thread-safety less likely.
The AOT-compilation occurs in the AOT-task now, and then we compile the result
using CompileTask.
This means that the error message in CompileTask was slightly incorrect, so
rectify it.
This makes dylibs automatically have the correct dylib id, which means no
fixups are required.
For instance: we'd build libpinvokes.armv7.dylib from libpinvokes.armv7.m,
which by default ends up with a dylib id of "libpinvokes.armv7.dylib". With
this fix no change is required, since we now build armv7/libpinvokes.dylib
from armv7/libpinvokes.m.
Compute the dependency map for assemblies earlier, and store the results.
In a later commit we'll need to know if a dependency map was successfully
computed when determining if a task is up-to-date or not.
Rework the code that copies assemblies and their related files to the app
bundle to take into account that we might be building to frameworks now.
Also strip the assemblies when they're copied (if they must be stripped),
which removes the need for custom logic to copy files related to stripped
assemblies.
Additionally change how we handle duplicated assemblies by checking for
duplication before copying them to the app bundle. This allows us to copy
assemblies to the root directory (not the .monotouch-[32|64] subdirectory) if
the 32-bit and 64-bit versions are identical, which also means we won't need
symlinks anymore.
Make the architecture a suffix instead of infix for aotdata filenames so that
it's easier to compute the filename from the assembly name without passing
printf-style format strings around.
Alex Soto
Alex Soto
Rolf Bjarne Kvinge
Vincent Dondain
Timothy Risi
Andy Martin
Marius Ungureanu
Chris Hamons
Andi McClure
Sebastien Pouliot
Marek Safar
Vlad Brezae
Zoltan Varga