* xtro: Fix how we build the u2todo project to actually build the correct project.
* Don't import eng/Versions.props in several test projects, it's already imported in a Directory.Build.props further up the directory hierarchy.
This test doesn't work when building on iossimulator-arm64 or
tvossimulator-arm64, because we're trying to use a fat framework which doesn't
have that architecture (it contains the device arm64 architecture instead).
So just disable this test on iOS and tvOS - the solution is using an
xcframework, and we already have a different test for that.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Add support for binding constructors in protocols.
Given the api definition:
```cs
[Protocol]
public interface Protocol {
[Abstract]
[Export ("init")]
IntPtr Constructor ();
[Export ("initWithValue:")]
IntPtr Constructor (IntPtr value);
[BindAs ("Create")]
[Export ("initWithPlanet:")]
IntPtr Constructor ();
}
```
we're binding it like this:
```cs
[Protocol ("Protocol")]
public interface IProtocol : INativeObject {
[Export ("init")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithValue:")]
public static T CreateInstance<T> () where T: NSObject, IProtocol { /* default implementation */ }
[Export ("initWithPlanet:")]
public static T Create<T> () where T: NSObject, IProtocol { /* default implementation */ }
}
```
Also add documentation and tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14039.
---------
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@soto.dev>
Add support for the LinkWithSwiftSystemLibraries metadata to specify whether a native library is a Swift library, in which case we'll automatically set the `LinkWithSwiftSystemLibraries` MSBuild property to `true`.
Also add a test.
Once upon a time we needed to special case a higher min OS version that the
min OS version we supported for certain compiler/linker arguments, because we
used features not supported in the min OS version we supported.
That time has passed; in all cases our min OS version is now higher than the
special-cased min OS versions passed to native compilers/linkers, so we can
just use the actual min OS version we support.
The ResolveNativeReferences task would incorrectly set Kind=Framework for static
libraries and dylibs if these files came from an XCFramework in the runtimes/native
directory in a NuGet (as opposed to a binding project, or the NuGet built from a
binding project).
Fix this by properly assigning the Kind and PublishFolderType metadata for such static
libraries and dylibs.
Also add a test.
For a given dylib named '/path/to/libMyLibrary.dylib', we pass this to the native linker:
-L/path/to -lMyLibrary
however, that doesn't work unless the dylib's name starts with 'lib'.
So detect this, and if the dylib doesn't start with 'lib' (say it's just
'MyLibrary.dylib'), then just pass the path to the dylib as-is to the native
linker:
/path/to/MyLibrary.dylib
Fixes https://github.com/xamarin/xamarin-macios/issues/15044.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
'dotnet build' doesn't work when MSBUILD_EXE_PATH is set (which we do in
some places for legacy tests), so make sure to unset MSBUILD_EXE_PATH before running
'dotnet build'.
This will be required when we make blocks use blittable callbacks, since we'll
have to use pointers in a few cases (because ref/out arguments aren't
blittable).
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230202.11
- **Date Produced**: February 2, 2023 10:28:14 PM UTC
- **Commit**: 5c7737d740c861fe7cda4822a7137c22368000dc
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.23077.6 to 8.0.100-preview.2.23102.11][1]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1][4]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2][5]
[1]: 1d88a6b...5c7737d
[2]: c790896...842ec4a
[3]: 4d75ee9...56cb24c
[4]: ff23620...5b46122
[5]: 007df05...842ec4a
Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 7.0.100-1.22564.1 to 8.0.100-1.23055.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230113.2
- **Date Produced**: January 13, 2023 12:09:55 PM UTC
- **Commit**: e0284b3f3c72d8f21e4825ed1ac723d2e829d0a5
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.22605.6 to 8.0.100-alpha.1.23063.2][191]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22564.1 to 8.0.100-1.23055.2][192]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7][193]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2][194]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1][195]
[191]: cbc7313...e0284b3
[192]: 13b8d6d...4b3f78c
[193]: 1bee0af...cefc6cc
[194]: dd7fdb7...5da4a9e
[195]: b6656f5...66b9845
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Dynamic libraries might be deployed in subdirectories such as libclrjit.dylib from the nuget package cefglue.common:
Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
The library ID for that library should be: @executable_path/../MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Instead of: @executable_path/../MonoBundle/libclrjit.dylib
Beside the library ID being wrong, when it's combined with the nuget package microsoft.netcore.app.runtime.osx-x64 providing a library with the same name, both uses the same `ReidentifiedPath`, which can cause a failure in the InstallNameTool tasks that are run in parallel operating on the same temporary file.
The following patch uses the `RelativePath` for the tempory file used by `InstallNameTool` so that there are no clashes with other files with the same name deployed in other directories. It also uses the `RelativePath` to create the correct library id: @executable_path/../../Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Partially fixes https://github.com/xamarin/xamarin-macios/issues/15173 for this scenario
Fixes this:
Making all in frameworks
/bin/sh: .libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll: No such file or directory
make[2]: *** [.libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll] Error 1
Since executables in frameworks usually don't have dots, `%(Filename)` will be
the entire filename, because `%(Extension)` is empty. However, if the
executable happens to have a dot, then we need to include the extension:
`%(Filename)%(Extension)`.
Fixes https://github.com/xamarin/xamarin-macios/issues/15727.
When we changed SCNMatrix4 to be column-major instead of row-major in .NET, there
were several other related changes we should have done but didn't do. In particular
we should have made transformation operations based on column-vectors instead of
row-vectors.
In legacy Xamarin, a vector would be transformed by a transformation matrix by doing
matrix multiplication like this:
[ x y z w] * [ 11 21 31 41 ]
| 12 22 32 42 |
| 13 23 33 43 |
[ 14 24 34 41 ]
In this case the vector is a row-vector, and it's the left operand in the multiplication.
When using column-major matrices, we want to use column-vectors, where the vector
is the right operand, like this:
[ 11 21 31 41 ] * [ x ]
| 12 22 32 42 | | y |
| 13 23 33 43 | | z |
[ 14 24 34 41 ] [ w ]
This affects numerous APIs in SCNMatrix4, SCNVector3 and SCNVector4:
* The M## fields have been changed to make the first number the column and the
second number the row, to reflect that it's a column-major matrix (this is
also how it's defined in the native SCNMatrix4 type).
* Functions that return a transformation matrix have been modified to return column-vector
transformers. Technically this means that these matrices are transposed compared
to legacy Xamarin. The functions involved are:
* CreateFromAxisAngle
* CreateRotation[X|Y|Z]
* CreateTranslation
* CreatePerspectiveFieldOfView
* CreatePerspectiveOffCenter
* Rotate
* LookAt
* Combining two column-vector transforming transformation matrices is done by multiplying
them in the reverse order, so the Mult function (and the multiplication operator)
have been modified to multiply the given matrices in the opposite order (this matches
how the SCNMatrix4Mult function does it). To make things clearer I've changed the
parameter names for XAMCORE_5_0.
* Functions that transform a vector using a transformation matrix have been modified
to do a column-vector transformation instead of a row-vector transformation. This
involves the following functions:
* SCNVector3.TransformVector
* SCNVector3.TransformNormal
* SCNVector3.TransformNormalInverse
* SCNVector3.TransformPosition
* SCNVector4.Transform
* Numerous new tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/15094.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
* Make the custom-type-assembly library build using assemblies relative to
MAC_DESTDIR, instead of poking into $(TOP)/_mac-build (for legacy Xamarin).
* Build the custom-type-assembly using a project file for .NET (and use our
local .NET).
* Change the default for [IOS|MAC]_DESTDIR when TESTS_USE_SYSTEM is set to
point to the system installation.
* Make sure 'MSBuildSDKsPath' isn't set when building the custom-type-assembly
(set by xibuild), it breaks a lot of things.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Andoni Morales Alastruey
Alex Soto