Regression from:
----------------
commit e5d012c5b8
Author: Chris Hamons <chris.hamons@xamarin.com>
Date: Mon Aug 14 13:17:10 2017 -0500
[macos] System mono should resolve non-XM libraries from system (#2480)
----------------
The way this manifests is that for (eg.) a `TargetFrameworkName=Full` project,
after the `FixTargetFrameworkDirectory`(X.M.Common.targets) target we end up with
`$(TargetFrameworkDirectory)` having value of:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5
/Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/4.6.1-api/Facades/
.. and the second path is incorrect. It should have been:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5/Facades
This path fixup is done by `FixDesignTimeFacades` (X.M.msbuild.targets)
target, but this target is running *after*
`FixTargetFrameworkDirectory`, so it doesn't see the fixed facade path!
Both `FixTargetFrameworkDirectory` and `FixDesignTimeFacades` have
`AfterTargets="GetReferenceAssemblyPaths`. But since
`FixTargetFrameworkDirectory` is defined before the
`Xamarin.Mac.msbuild.targets` import, so it gets executed before
`FixDesignTimeFacades`.
Pick up:
commit ebbd5b492321d092feae425e8f7aefc3c273530e (HEAD -> d15-4, origin/d15-4)
Author: Marek Safar <marek.safar@gmail.com>
Date: Wed Aug 23 00:44:47 2017 +0200
Don't crash on any wrong type forwader reference
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=58063
We need the 'mono_profiler_startup_log' symbol when profiling is enabled, so
make sure to add the symbol to the correct list of symbols we need.
Previously we were passing `-u _mono_profiler_startup_log` to clang directly,
which is fine, but not complete, since it does not write the symbol to the
symbollist file (--symbollist=file), which means it wouldn't be preserved when
the MSBuild tasks strip the executable.
https://bugzilla.xamarin.com/show_bug.cgi?id=58778
Using the FullPath property breaks the build from Windows, since the metadata will contain a Windows path.
Partial fix for Bug #51759 - Getting build error for iOS sample 'Simpleapp-with-framework'
https://bugzilla.xamarin.com/show_bug.cgi?id=51759
- https://bugzilla.xamarin.com/show_bug.cgi?id=57718
- Unable to move until XAMCORE_4_0 as would be breaking change
- NSServicesMenuRequestor APIs were never on NSApplication / NSApplicationDelegate
- RegisterServicesMenu / OrderFrontStandardAboutPanel / OrderFrontStandardAboutPanelWithOptions are only on Application, not delegate
https://bugzilla.xamarin.com/show_bug.cgi?id=58479
_AssignAppExtensionConfiguration assigns project configuration from
`$(CurrentSolutionConfigurationContents)`, using the
`AssignProjectConfiguration` task, which is set if
`$(BuildingSolutionFile)` or `$(BuildingVisualStudio)` is true. We check
only for the former. It would be simpler to just check for ..
`$(CurrentSolutionConfigurationContents) != ''`
.. like the iOS targets. This mapping from this task is used when
invoking `GetBundleTargetPath` on the extension project:
Properties="%(_AppExtensionReferenceWithConfigurationExistent.SetConfiguration); %(_AppExtensionReferenceWithConfigurationExistent.SetPlatform)"
Details:
This failed for a project that had a reference to an app extension
project, with VSMac/msbuild. The app extension project was being built
with `Configuration==Debug` and `Platform==x86` for which the project
does not define any properties (like `$(OutputPath)`).
When the main project is built, we invoke `GetBundleTargetPath` on
the extension project, which in this case, has a different
config+platform mapping than the one for the referencing project. But
since the earlier `AssignProjectConfiguration` was skipped due to the
incorrect condition, `GetBundleTargetPath` is invoked with no
config+platform, thus falling back to extension project's defaults.
Note: The referencing project was being built with Debug|x86 and the
referenced project was expected to be built with Debug|AnyCPU .
This project:
- VSMac/xbuild - Works
- This happens to work because the default from the extension
project is Debug|AnyCPU, so even though
`AssignProjectConfiguration` didn't set those properties, it
builds just fine.
- command line xbuild/msbuild - works!
- `AssignProjectConfiguration` works because this time the
condition `$(BuildingSolutionFile) == 'true'` is True.
- VSMac/msbuild - fails
- In this case, the default case does not work because in VSMac,
we use `SetGlobalProperty` to set config+platform properties
when starting the build for the referencing project.
- And when the referencing project builds the referenced project
(via `GetBundleTargetPath`), it is built with config+platform
global properties set, and thus defaults from the referenced
don't get picked up!
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
- With the `AssignProjectConfiguration` fix, we set the
properties via the `MSBuild` task, so it works.
But this needs to be fixed in VSMac anyway.
This can save a significant amount of space when using code-sharing: the PIX
app saved ~11mb in release mode (when stripping).
`man strip` says:
```
For dynamic shared libraries, the maximum level of stripping is usually -x (to remove all non-global symbols).
-x Remove all local symbols (saving only global symbols).
```
Fix collecting required internal symbols which aren't in the objc_msgSend
family by not bailing out early for a function which isn't in the objc_msgSend
family.
Also add a test.
For some reason the target to build OpenTK.dll.config may cause an infinite
recursion in make.
I don't understand what's happening, but we don't need OpenTK.dll.config
anymore, so just not produce/ship it anymore.
Ankit Jain
Luis Aguilera
Chris Hamons
Sebastien Pouliot
Sebastien Pouliot
Rolf Bjarne Kvinge
Emanuel
Vincent Dondain
Matt Sylvia