That's in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/SDKs/Xamarin.macOS.sdk/[lib|include]
This allows for a bit more code share between mtouch and mmp.
[linker] Don't pass information to linker steps by selectively creating them or using constructors.
Instead use the built-in logic to determine if a linker step should light up,
and use information available in the LinkContext to determine how steps should
behave.
This is required for .NET, where linker steps can't have custom constructors.
Several steps have not been modified, because they're not all required in .NET.
Some are no longer part of the SDK (or converted into new ones
at build time), others were new (and missing).
A full list of attributes and their usage frequency in what we ship can
be seen in https://gist.github.com/spouliot/ca03c6da7d4d75670ca77749350eb8a2
Also update tests: no need to check for removals of stuff that does not
exists anymore.
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
The fact that the mobile profile allows linking doesn't mean it should be done
(it doesn't actually link because we run the registrar before linking happens,
but this way the code is less confusing and there are no unnecessary
differences between full and mobile).
`monotouch-glue.m` was replaced a while ago and the new code does not
need `Class.LookupFullName` to be preserved in debug builds.
Also `PreserveType` was unused code (left from even older times?)
Always add `libmono-profiler-log.dylib` if profiling is enabled and we
are building with dynamic libraries. The profiler code is not (meant to
be) shipped so it can be added even without a `Frameworks` directory.
This fix debugging too (if profiler is enabled) since the library was
linked (even if it was not included).
Fix https://github.com/xamarin/xamarin-macios/issues/8470
The native methods xamarin_get_[generic_]method_from_token are a bit unusual
in that they return an actual GCHandle. This is for performance reasons, since
in some cases their return value is passed as parameters to other function
calls to managed code, in which case we need the GCHandle. This way we avoid
round-tripping a GCHandle multiple times.
The previous pattern would match the output files we created from processing
these directories, and somehow the pattern would match such a file (even
though the pattern should only be executed before doing any processing, when
those files don't exist yet, so I don't know exactly why this is happening),
leading us to try to process those files as if they were directories with
sample data in, with the predictable (disastrous) result.
Fixes https://github.com/xamarin/maccore/issues/2202.
xamarin-storage can not be reachable or a network issue might happen
when we try to provision the dependencies. In that case, skip those
tasks that are skipped when we cannot provision the certs.
The provisioning dependencies will only execute in the provisioning
profiles was successful, therefore, the if statement is not stepping in
any value that was set by the profiles step.
Add timeouts to the steps to catch possible issues when a step takes
longer than expected. Numbers have been taken from common runs and
rounded up a little to have some buffer.
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
Rolf Bjarne Kvinge
Sebastien Pouliot
Sebastien Pouliot
Manuel de la Pena