commit xamarin/maccore@14c3eca3aa
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Fri Nov 24 09:53:13 2017 +0100
Bump mac-api-docs.
commit xamarin/mac-api-docs@057bb83848
Author: Timothy Risi <timothy.risi@xamarin.com>
Date: Thu Nov 23 23:52:21 2017 -0900
Docs should also be generated for Xamarin.Mac (#2)
* Docs should also be generated for Xamarin.Mac
* Remove the push target
commit xamarin/maccore@bb3ebb634f
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Thu Nov 23 19:06:51 2017 +0100
[tests/external/device-builds] Use BUILD_WORK_HOST instead of BUILD_HOST so that we calculate the right wrench url.
Detect MT1111 from mlaunch (which means mlaunch won't wait for the app to
exit), and instead use test run completion to determine test completion.
The main drawback is that if the test app crashes, it won't be detected (the
test run will time out, and reported as such), but it's still an improvement
over the current behavior (the tests may complete successfully, and still be
reported as timed out).
This also requires bumping maccore to get an updated mlaunch (one that reports
MT1111).
commit 287cbcf72d81e185f6d9d9534bcd558a718d8001 (HEAD -> master, upstream/master, upstream/HEAD)
Author: Vincent Dondain <vidondai@microsoft.com>
Date: Wed Oct 25 11:33:11 2017 -0400
Bump maciostools to get unlock device warning code
commit af38985deb3dd4ce6f5cf33de921cea602e1e8e1 (HEAD -> master, origin/master, origin/HEAD)
Author: Vincent Dondain <vidondai@microsoft.com>
Date: Fri Oct 20 14:36:18 2017 -0400
[Xamarin.Hosting] Update '--wait-for-unlock' error message (#94)
- Use same `1031` error code as in `controller-device.cs`'s `LaunchBundleIdOnDevice`.
- Simplify message to not mention passcode as there are other ways to unlock a device.
- This change is needed to show up the alert dialog in https://github.com/xamarin/md-addins/pull/2590.
commit xamarin/maccore@9b9dd1c752
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Thu Oct 19 11:04:50 2017 +0200
Bump maciostools to get better error reporting in mlaunch.
commit xamarin/maciostools@4967539783
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Thu Oct 19 10:45:27 2017 +0200
[Xamarin.Hosting] Be a bit more defensive with nulls when something goes wrong to try to get helpful error messages instead of NREs.
* [tests] Add makefile target to run device tests and bump maccore to get automated VSTS triggering.
* [tests] Rename device-testing makefile target to make it clearer, and add a comment about it.
* Colorize dependency checks to make them nicer (and easier to see if something is ignored).
Also print any ignored readme-style dependencies (previously we only printed
ignored submodule-style dependencies).
* Ignore any errors when fetching console colors sequences.
It's not a serious problems to not have colors, so just ignore any problems.
Makes this message go away on bots:
> tput: No value for $TERM and no -T specified
* [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes#57966.
Also bump maccore to get an mlaunch error for launching a 32-bit app in a 64-bit-only simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=57966
* [tests][msbuild] Make sure all Info.plists have deployment targets.
Otherwise we get different behavior (32-bit allowed or not) depending on which
Xcode is used to build.
* [mtouch] Default to 64-bit arch if not specified and targeting iOS 11+.
* [tests] Tweak tests to either specify a deployment target < 11 or not build a 32-bit arch.
- Update Versions-ios and Versions-mac file too.
- Bump maccore and maciostools to the xcode9 branch.
- [builds] Force disable 'futimens' and 'utimensat' so that we build with Xcode 9.
- [builds] 'system' is not available on iOS (simulator).
- [runtime] Fix: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
- Prevented building xcode9 branch, see: https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/3886/console
```
runtime.m:1122:9: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
char *last_sep = strrchr (info.dli_fname, '/');
```
- [registrar] Apple removed a header, so don't include it anymore.
- [mtouch] Don't run the partial static registrar for tvOS.
The generated output doesn't compile because Apple forgot to ship headers for
the ExternalAccessory framework in their tvOS simulator SDK.
* [builds] Improve mono/llvm dependencies.
* Create a list of all the files in the mono and llvm repositories, and save
these lists as a Make variable (in a generated Makefile - .deps.*.mk). We
don't list _all_ the files in each repository, because there are quite a few
(55k for mono), and Make measurably takes a while to check all of them, so
try to limit it to a sane subset, without risking missing changes to files
that actually matters.
* Always create stamp files when we're done with mono builds.
* Modify the mono/llvm builds to depend on all the files in their
repositories.
* Explicitly list the corresponding .stamp-build-* files as dependencies for
various files that are produced by the mono builds, so that make knows how
to build these files.
* Rewrite the *-facade-check targets to depend on the corresponding
*_BCL_TARGETS, so that we can avoid running a submake to the same Makefile
to execute the facade checks.
It now takes a little while (less than a second on my machine, which is
fine) for make to list all dependencies and get their timestamps, but if
executing multiple submakes this adds up to a multi-second timewaste.
So avoid the timewaste by not doing submakes, but instead use dependencies
to enforce the required target execution ordering.
* Don't depend on nicely named intermediate targets, since won't prevent
rebuilds:
build-cross64: setup-cross64
Since the `setup-cross64` file doesn't exist, `build-cross64` will always
execute. Instead depend on the stamp file:
build-cross64: .stamp-configure-cross64
And now `build-cross64` will only rebuild if needed.
* Don't try to list all intermediate files as .SECONDARY dependencies, instead
list none at all, which works as if all files were listed as dependencies.
* Some targets had to move later in the file, since variables used in dependencies:
foo: $(VARIABLE)
must be defined before that point in the file, as opposed to variables used in recipes:
foo:
$(MAKE) $(VARIABLE)
can be defined anywhere in the Makefile.
* Simplify the targets that sign assemblies significantly.
There are a few end results:
* It's now possible to do `make install`, without doing `make all` first. This
might seem weird, but that also ensures the more common `make all install`
works properly.
* Remakes (without any mono/llvm changes) in build/ are much faster, because
we now won't recurse into every mono build:
$ time make all -C builds/ -j8
[...]
real 0m1.873s
This even means that we might be able to make it a habit to remake in the
root directory, which doesn't take forever now:
$ time make all -j8
[...]
real 0m4.521s
Unfortunately adding `make install` to the mix still does some useless
stuff, and it ends up taking ~30 seconds to complete a full build:
$ time make all install -j8
[...]
real 0m32.542s
* [msbuild] Don't verify the xml syntax of targets files unless the files change.
* [build] Don't depend on installed files.
Don't depend on installed files, because that causes a rebuild when installing
to a different directory (i.e. package creation).
* Bump maccore to get build improvements.
Rebuilds are now very fast:
$ make all install -j8
$ time make all install -j8
real 0m5.735s
Less than 6s to figure out that nothing needs to be done.
And strangely flushing the disk cache doesn't make it much slower:
$ sudo purge
$ time make all install -j8
real 0m7.309s
Which probably means that Make mostly reads file metadata, and not actual file
contents (which is good).
* Bump maccore to get fix for launching the simulator for app extensions.
* [runtime] Don't look in shared memory for debug data in normal apps.
Don't look in shared memory for debug data in normal apps, because it
interferes when debugging extensions from the same solution as a container
app:
Example, for a keyboard extension:
1. Run extension in XS.
2. Manually launch the extension's container app (which contains a textbox
that can be used to launch the keyboard).
3. The container app reads the debug data in shared memory which was intented
for the extension, and takes over the debugger.
4. Launch keyboard, which will not be able to connect to the IDE because the
container app already connected to the IDE.
* Bump maccore to get partial fix for bug #52710.
Bump maccore to get partial fix for bug #52710 (can't launch/debug today
extensions more than once).
https://bugzilla.xamarin.com/show_bug.cgi?id=52710
* Bump maccore to make the (partial) fix for #52710 work on device as well.
* Bump maccore to get new mlaunch.
A new mlaunch that:
* Should have fewer random failures when launching watchOS apps.
* Supports launching extensions on device.
* Supports uninstalling apps from devices.
* [msbuild] Remove unused FrameworkList.xmls
* [msbuild] Make files in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS the real deal, not a symlink.
* [msbuild] Make /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS a symlink, instead of each file inside.
* [msbuild] Don't put anything in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1 anymore.
* [msbuild] Remove support for XI/Classic binding projects.
* Improve 'install-system' to clean up old files.
* [msbuild] Simplify XI/Classic targets files a bit.
* [msbuild] Remove dead XI/Classic code.
* Bump maccore to get fix for xamarin-analysis.
commit xamarin/maccore@34c04c2bf1
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Mon Oct 10 16:46:18 2016 +0200
[analysis] Update to put files in /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS.
XI/Classic is being removed now, which means files should go into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS/ instead of into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1.
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
The watchOS device has limited networking support; in particular
it does not allow inbound/output network connections using 'bind'
(kernel-level sandbox restrictions).
This means that we can't use BSD sockets to connect to the debugger
in the IDE on the desktop. Instead we create an http tunnel that
knows how to convert socket send/recv data into http requests on
both sides.
https://bugzilla.xamarin.com/show_bug.cgi?id=41554
The watchOS device has limited networking support; in particular
it does not allow inbound/output network connections using 'bind'
(kernel-level sandbox restrictions).
This means that we can't use BSD sockets to connect to the debugger
in the IDE on the desktop. Instead we create an http tunnel that
knows how to convert socket send/recv data into http requests on
both sides.
https://bugzilla.xamarin.com/show_bug.cgi?id=41554
This fixes the following problem:
* xamarin-macios is cloned
* xamarin mode is enabled
* make world is executed
* The maccore repo will be cloned immediately
* make reset-versions will be executed, which will reset the maccore version.
If this brings a new version of maccore, maccore dependencies might be
out of date.
* make all will be executed, which may fail because some dependencies
are out of date.
Instead check if the maccore directory exists.
This prevents an issue where if the stamp file did not exist and
the maccore directory did, we'd reset the maccore directory even
for make targets that shouldn't change anything (such as 'check-versions').
* [XM] Teach XM's mmp tool to handle read only assemblies/native libs
- https://bugzilla.xamarin.com/show_bug.cgi?id=41037
- mmp should also promote any install_name_tool errors to "real" errors
* Bump maccore
[Xamarin.Hosting] Set a default simulator if nothing is provided to mlaunch. Fix#41083 part 3
The string to represent a specific simulator is not something you can
easily remember but it's often not very important.
This will start the most basic simulator, by default, instead of throwing
an NRE that does not mention a (now un-) required parameter is missing.
> Failed to launch the simulator: Object reference not set to an instance of an object
> error MT1008: Failed to launch the simulator: Object reference not set to an instance of an object
https://bugzilla.xamarin.com/show_bug.cgi?id=41083
Also bump maccore to get new test.
commit xamarin/maccore@eb9c34d875
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Fri May 13 12:46:04 2016 +0200
[monotouch-test] Add test to ensure mtouch properly links with CoreAudioKit when not using simlauncher.
It is apparently common to have references to assemblies that can't
be resolved when building apps with the linker disabled, so we need
to support that.
So add a custom reference loading step that only shows a warning
for unresolvable assemblies.
Also bump maccore to add a test.
commit xamarin/maccore@190c67d855
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Tue May 10 18:14:04 2016 +0200
[tests] Add test case for bug #40786.
https://bugzilla.xamarin.com/show_bug.cgi?id=40786https://bugzilla.xamarin.com/show_bug.cgi?id=40786
To get a version of mdtool that works without any Xamarin.Mac
licenses.
Also bump maccore to run the mmp regression tests now that
we have a working Xamarin Studio.
commit xamarin/maccore@9a5e6f02f3
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Tue May 10 18:20:48 2016 +0200
[tests] There is now a released version of Xamarin Studio whose mdtool doesn't care about the XM license, so we can run the mmp regression tests again.
commit xamarin/maccore@8cc7ade11c
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Tue May 10 12:16:47 2016 +0200
[xharness] Find and parse config files in xamarin-macios as well.
Should make the watchos tests run again on wrench.
Fix ApiSelectorTest for NSImage initByReferencingFile:
Commit 8b400722fb introduced
a new InitByReferencingFile internal method bound to initByReferencingFile:
Therefore the mac don't link tests were complaining because that selector
was used on a method and not a constructor.