You were the preprocessor we wished C# had natively
Removing PMCS requires these changes:
* Remove XamCore from src/
* Remove XamCore from tools/
* Remove XamCore from runtime/
* nint/nuint enum conversion
* _compat_ enum conversion
* NSAction conversion
* Hand fix single API incorrectly converted by PMCS to unbreak compatibility
- Due to a bug in PMCS, the nuint was incorrectly converted in this API.
- However, as that ship as sailed, we must "fix" it until XAMCORE_4_0
* Update readme
* Bump macios-binaries
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.
1. Add an --optimize flag to mtouch/mmp that allows users to select which
optimizations to apply (or not). This makes it easier to add future
optimizations, and allow users to disable any optimization that causes
problems without having to disable many other features.
2. Share as much optimization code as possible between mtouch and mmp. This
immediately gives a benefit to mmp, which has three new optimizations only
mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
dead code elimination.
This results in ~6kb of disk space saved for a linked Xamarin.Mac app:
* link sdk: [Debug][1], [Release][2]
* link all: [Debug][3], [Release][4]
Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.
[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64
* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.
* Fix whitespace issues.
* [doc] Document optimizations.
* Officially support optimizations by adding them to the Versions.plist.
* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.
* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
the Application's value will be incorrect when building fat apps (both
Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
does not depend on other instructions than the IntPtr.get_Size call, so
remove the checks that verify surrounding instructions. This makes the
IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.
* [tests] Add mmp tests for optimizations.
* [tests] Fix XM optimization tests.
* [tests] Fix test build error.
The parsing done by `System.Version` does not accept a major-only string,
e.g. providing "11" would throw an exception.
Since people generally refer version as iOS 11 (and not iOS 11.0) this
is, at best, a nuisance. Xcode toolchain accept "11" as a valid string.
The first part of message was updated to show both the option name and
the (user provided) value.
The 2nd part remain the text of the .net exception message, i.e. what
`Version.Parse` tells you when it validates the string. Seeing the input
value should make it more obvious for other, incorrect version strings.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=60280
* [mtouch/mmp/bgen] Add support for response files.
This is the first part of the fix for #56501.
https://bugzilla.xamarin.com/show_bug.cgi?id=56501
* [tests] Make sure no single argument starting with a '@' is passed to mtouch unless it's a response file.
--assembly-build-target takes arguments starting with '@', for instance:
--assembly-build-target @all=framework
which does not work anymore, because that's interpreted as a response file
(mtouch tries to read the file '@all=framework', which obviously doesn't
exist).
The fix is simple, don't put a space between the two arguments:
--assembly-build-target=@all=framework
* Add --root-assembly to mtouch/mmp and make the MSBuild tasks use this new option.
This makes it possible to pass root assemblies starting with `@` to mtouch/mmp
without getting mistaken for response files.
* [msbuild] Always use the command-line option that takes an equals or colon.
Always use the command-line option that takes an equals or colon instead of a
space.
Do either of these:
--foo=something
--foo:something
instead of this:
--foo something
so that `something` can start with an at (`@`) sign without being mistaken for
a response file.
* [msbuild] Fix tests according to recent task changes.
* Update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now.
* [builds] Pass --with-cross-offsets= to crosstv's configure.
* Bump mono to 2017-08.
* Bump mono to 2017-08.
* Force disable 'futimens' and 'utimensat' so that we build with Xcode 9.
This is also needed to build with Xcode 8.3 on High Sierra.
* Remove old AppleTls implementation.
* Bump mono.
* Bump mono to 2017-08.
* Bump mono to 2017-08
* Reenable link-keep-resources-2 test
- This reverts commit 76b759ef22.
- 2017-08 has linker fix
* Bump mono to 2017-10
* Revert "Bump mono to 2017-10"
This reverts commit bb7832724e.
* Bump system mono to 2017-10
* Bump embedded mono to 2017-10
* [runtime] reflect eglib move
9be68f8952
* bump mono
* [btouch] remove Security.Tls usage from test
* [mtouch tests] update the function name used to initialize libmono-profiler-log, its called mono_profiler_init_log () now.
see
ea4e4a9ef6
fixes:
```
1) Failed : Xamarin.MTouch.Profiling(tvOS)
_mono_profiler_startup_log
Expected: collection containing "_mono_profiler_startup_log"
But was: < "_mono_profiler_init_log" >
at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0
2) Failed : Xamarin.MTouch.Profiling(watchOS)
_mono_profiler_startup_log
Expected: collection containing "_mono_profiler_startup_log"
But was: < "_xamarin_get_block_descriptor", "_mono_profiler_init_log" >
at Xamarin.MTouch.Profiling (Xamarin.Profile profile) [0x00106] in <511889694a624cc9a50e0e9b259b05c5>:0
```
* [mmptest] update log profiler options.
826558a4af
deprecated the dash prefix for the mlpd path.
`noallocs` or `nocalls` are not needed, neither of them are default anymore.
* [mmptest] fix link-keep-resources-2 test to cope with more corlib resources.
another corlib resource (mscorlib.xml) was added:
https://github.com/mono/mono/commit/11e95169e787#diff-2d1c64decd91d9a6e8842ab0f0e9438d
* Revert "[mmptest] fix link-keep-resources-2 test to cope with more corlib resources."
This reverts commit 350eb3c174.
* [XHarness] Add the Mono.Data.Tds tests.
* Address comments from rolf in the review.
* [mmp regresssion tests] bump mono linker, so mscorlib.xml gets stripped
the test was failing in that way:
> Executing link-keep-resources-2...
> [FAIL] i18n 4/2 data files present: charinfo.nlp, collation.core.bin, collation.tailoring.bin, mscorlib.xml
also update the output, because it's actually expected at least three
elements.
fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=59277
* bump mono
fixes crash in tvOS: https://github.com/mono/mono/pull/5812
* bump mono for updated BCL tests
see https://github.com/mono/mono/pull/5820
* [mono] set 2017-10 branch in .gitmodules
* [macos] Fix guiunit error on clean builds by depending on correct copy (#2912)
* [macos] Fix guiunit error on clean builds by depending on correct copy
- From a clean build making a BCL test would error due to the non-mobile guiunit not being built
- This was because the Makefile-mac.inc target was incorrect
- This was because xharness assumed that non variation based targets were always Modern
- However, BCL tests are Full, not Modern
* Code review change
* Swap to var to reduce diff
* Revert changes in the paths for GuiUnit.
* [XHarness] Add the System.IO.Compression bcl tests. (#2918)
* [XHarness] Add the System.IO.Compression bcl tests.
* [XHarness] Add bcl tests for System.IO.Compression.FileSystem. (#2924)
* [XHarness] Add the System.IO.Compression bcl tests.
* Ensure that resources are correctly copied in the bundles.
* [XHarness] Add bcl tests for System.IO.Compression.FileSystem.
* As per review, make the Mac test app name match the tests that are ran.
* [XHarness] Add Mono.CSharp tests on ios. (#2927)
* [XHarness] Add Mono.CSharp tests on ios.
* Bump mono to bring changes in the mono.csharp tests.
* [xtro-sharpie] fix TypeDefinition access due to Cecil change
* Bump mono
* bump mono
fixes
- https://bugzilla.xamarin.com/show_bug.cgi?id=60480
- https://bugzilla.xamarin.com/show_bug.cgi?id=60482
* bump mono
more fixes around conflicting paths when tests are run in parallel.
* Bump for mono/mono@2017-10
* [mtouch/mmp] Set CultureInfo.CurrentCulture according to LANG.
This makes it easier to run mtouch/mmp under different locales when testing.
Unfortunately mono checks the system locale before checking LANG, which means
that there's no built-in way in macOS/mono to specify the current locale
without changing the system locale.
* [mtouch] Print verbosity using an invariant culture. Fixes#58849.
https://bugzilla.xamarin.com/show_bug.cgi?id=58849
* [mtouch/mmp] Fix error code.
* [mtouch/mmp] Log/warn when we set the current language.
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.
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
* [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).
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.
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
* 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
- 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
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.
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.
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
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).
According to Vlad it's not necessary to set MONO_GC_PARAMS during AOT-
compilation, since all MONO_GC_PARAMS options can be changed at runtime:
Rolf Kvinge [16:35] @vlad.brezae is this true for all the different options MONO_GC_PARAMS take: https://github.com/xamarin/xamarin-macios/pull/1546#discussion_r97318092?
Rolf Kvinge [16:36] I remember this: https://bugzilla.xamarin.com/show_bug.cgi?id=35414#c14
Rofl Kvinge [16:36] which apparently you changed here, so that it can be changed at runtime: https://bugzilla.xamarin.com/show_bug.cgi?id=35414#c27
Rolf Kvinge [16:36] but I don't know if this is true for all the options you can pass using MONO_GC_PARAMS
Vlad Brezae [16:41] yes, it should be true for all of them, that was a bug
Rolf Kvinge [16:41] ok, that's great news 😄
Performance tests
-----------------
This is for a new watchOS extension project, built for release.
* The default (currently -O2) optimizations: 41s ( baseline ) 30.027.060 bytes ( baseline )
* All optimizations disabled (`--llvm-opt=all=`): 17s (-24s = -59%) 32.978.312 bytes (+2.951.252 = +10%)
* Optimized for size (`--llvm-opt=all=-Os`): 36s ( -5s = -12%) 28.617.408 bytes (-1.409.652 = -5%)
* Optimized for more size (`--llvm-opt=all=-Oz`): 35s ( -6s = -15%) 28.601.016 bytes (-1.426.044 = -5%)
* Optimized slightly (`--llvm-opt=all=-O1`): 35s ( -6s = -15%) 28.666.556 bytes (-1.360.504 = -5%)
* Optimized a lot (`--llvm-opt=all=-O3`): 41s ( 0s = 0%) 30.403.996 bytes (+ 376.936 = +1%)
Conclusions
-----------
* The fastest build by far (less than twice as fast) is if optimizations are
disabled, but this adds a 10% size penalty (~3 MB in this test case),
compared to the baseline, and 15% size penalty (4.3 MB) compared to -Oz.
* -Oz seems to have the best overall results: at least as fast as any other
optimized build, and the smallest app as well.
Caveats
-------
Some optimizations might not work the AOT compiled code. The resulting
binaries have not been tested.
Event sequence:
* mtouch is executed with the linker disabled.
* The linker pipeline copies all input assemblies (since the linker is
disabled the assemblies don't change) into the PreBuild directory. This will
keep the original timestamps of the input assemblies.
* mtouch is executed again, when none of the input assemblies changed.
* The linker pipeline will re-execute, because it will see that at least one
of the input assemblies (at least the .exe) is newer than at least one of
the assemblies in the PreBuild directory (usually a framework assembly,
because those have the original timestamp from their install location).
Fix:
Touch all the assemblies in the PreBuild directory after the linker pipeline
executes the first time. This way the second time mtouch is executed, it will
find that all assemblies in the PreBuild directory have timestamps later than
all the input assemblies, so it will load the cached linked assemblies,
instead of re-executing the linker pipeline.
Build extensions and the container app in the same mtouch process, by storing
all the mtouch arguments when called to build extensions in a text file, and
then reloading those arguments when called to build the main app.
This is required if we want to share code between extensions and the
container.
Chris Hamons
Rolf Bjarne Kvinge
Sebastien Pouliot
Bernhard Urban
Timothy Risi
Marius Ungureanu
Alex Soto
Marek Safar
Vlad Brezae