* Update `SdkVersions.cs` after the latest Xcode 14.2 bump.
* Rename `[SdkVersions|ProductConstants].cs.in` to `[SdkVersions|ProductConstants].in.cs`.
This way the autoformatter makes sure it's formatted correctly.
We need parts of tools/common/SdkVersions.cs when building tests on Windows.
In order to simplify our Windows-life, we're going to check in the generated
SdkVersions.cs file, that way it won't have to be re-generated on Windows (the
logic is very make-based, and not easily executed on Windows).
However, parts of SdkVersions.cs would change every commit, which would make
the above solution rather annoying. So split out those parts into a new file
(ProductConstants.cs), which is still generated during the build (and not
checked in).
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Don't add a dot after showing another exception message, because that another
exception message might also add a dot.
Example:
> An exception occurred while trying to invoke the function System.Void VisualStudioMac.AppDelegate.DidFinishLaunching (Foundation.NSNotification): Object of type 'CoreLocation.CLLocationManager' cannot be converted to type 'Foundation.NSNotification'..
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Fixes this on the bots when iOS is not enabled even though legacy is:
+ make -C /Users/builder/azdo/_work/1/s/xamarin-macios/tools/mtouch package-introspection-dependencies.zip
make: *** No rule to make target `../../runtime/.libs/iphonesimulator/libxamarin-debug.a', needed by `simlauncher32-sgen'. Stop.
The Xamarin.MacDev.Tasks.sln solution is built with dotnet, while other projects
are still built with msbuild. This becomes a problem when generating Errors.designer.cs,
because depending on the runtime the output is different.
This means that the Errors.designer.cs will sometimes randomly change (depending
on which project re-generated the file), leaving the file modified in git. This is
quite annoying, but it also breaks the api comparison, which depends on the build
not leaving modified files behind. So for now, we generate Errors.designer.cs separately
for Xamarin.MacDev.Tasks.sln to not conflict with the mtouch version.
Also fix capitalization in numerous places to be consistent (it's Errors.designer.cs,
not Errors.Designer.cs).
Apple has deprecated bitcode, and will apparently reject app submissions
containing bitcode starting with Xcode 14. So automatically disable bitcode if
building using Xcode 14+ (and show a warning so that app developers can remove
the 'MtouchEnableBitcode' property from their project files).
Fixes https://github.com/xamarin/xamarin-macios/issues/15210.
Backport of #15804
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This PR has the AVKit updates and introduces the AVRouting bindings that
are interconnected with AVKit
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
This will increase app size a little bit: the space for the MVID + 4 bytes for each
assembly, but we'll be able to validate and show a helpful error message if the generated
static registrar code does not match the assembly loaded at runtime.
It's also a step toward per-assembly static registration (ref: #12067).
Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
A stack trace like this isn't all that helpful:
*** Terminating app due to uncaught exception 'System.Reflection.TargetException', reason: 'Object does not match target type. (System.Reflection.TargetException)
at System.Reflection.RuntimeConstructorInfo.CheckConsistency(Object target)
at System.Reflection.RuntimeConstructorInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at ObjCRuntime.Runtime.InvokeMethod(MethodBase method, Object instance, IntPtr native_parameters) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/Runtime.CoreCLR.cs:line 655
at ObjCRuntime.Runtime.InvokeMethod(MonoObject* methodobj, MonoObject* instanceobj, IntPtr native_parameters) in /Users/builder/azdo/_work/1/s/xamarin-macios/src/ObjCRuntime/Runtime.CoreCLR.cs:line 552
at ObjCRuntime.Runtime.bridge_runtime_invoke_method(MonoObject* method, MonoObject* instance, IntPtr parameters, IntPtr& exception_gchandle) in /Users/builder/azdo/_work/1/s/xamarin-macios/runtime/Delegates.generated.cs:line 1210
with this change we'll be told exactly which function we failed to call.
I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
The bug in the AOT compiler is being fixed, but until then we can just ignore
the warning, with the idea of removing this code once the AOT bug has been
fixed.
Fixes these MTouch test failures:
* Xamarin.MTouch.BuildWithCulture("sl_SI"):
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory107/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
* Xamarin.MTouch.BuildWithCulture("ur_IN"):
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory109/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
* Xamarin.MTouch.MT0095_NotSharedCode:
No warnings expected, but got:
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory274/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Native linking warning: warning: '/Users/builder/azdo/_work/2/s/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory272/mtouch-test-cache/arm64/Xamarin.iOS.dll.o' was built with class_ro_t pointer signing enabled, but previous .o files were not
Ref: https://github.com/xamarin/xamarin-macios/issues/14601
Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1505990/
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
TJ Lambert
Manuel de la Pena
Frank A. Krueger