* [jenkins] Add support for enabling device builds using labels.
* [xharness] Give the iOS MSBuild tests 30 minutes to finish.
* [mtouch tests] Give the BuildTestProject 10 minutes to compile each test case.
Wrench bots build the dontlink test in ~3m40, but that's apparently not enough
for the Jenkins bots (slower bots?), which time out the test after 5 minutes.
So double the timeout to 10 minutes, which will hopefully give the Jenkins
bots enough time to run the test to completion.
* [xharness] Don't crash if we can't find a simulator.
* [xharness] Create a device pair if none applicable is found.
* [xharness] Use an enum instead of string values for the target.
* [xharness] Unify the simulator selection code between Jenkins and Wrench.
* [Jenkins] Make test to write output as an xml file so that it can be parsed by the jenkins bot.
* Point to the correct Touvh.Unit repo.
* Use the available property to determine if we are being ran in Jenkins.
* Log where are test results stored.
* Add @MonkeyWrench: prefix.
* Ensure that we do set the build env in jenkins/run-tests.sh
* Do not mix Wrench with Jenkins. The reports in jenkins can be Xml, in Wrench we prefer the old style.
* Ensure that the main node of the unit tests does contain the target, that will improve the tests results reporting.
* Revert "Fix binding project LinkWithAttributes generation to prevent rebuilds" (#1018)
* Added xslt to be used to keep the old Test Reports until we move to only Jenkins reports.
* Add an extra log for the xslt transformation.
* Point to the correcto dir in jenkins.
* Deal with the xslt once we have finished rather than in a batch.
* Remove noise.
* Readd case removed in rebase.
* Fix indentation.
* Skip lock keychain.
- https://bugzilla.xamarin.com/show_bug.cgi?id=46508
Since we were previously looking for the .exe instead of the launcher, mmp
failures would come back as good and we wouldn't rebuild. What we want
to do is look for the native launcher, which we perviously were doing wrong.
Example log output when bumping mono:
> Found 1 modified file(s) in the pull request #1161.
> external/mono
> Enabled 'mtouch' tests because the modified file 'external/mono' matches prefix 'external/mono'
> Enabled 'mmp' tests because the modified file 'external/mono' matches prefix 'external/mono'
> Enabled 'bcl' tests because the modified file 'external/mono' matches prefix 'external/mono'
> Found 1 label(s) in the pull request #1161: cla-already-signed
Or when changing the static registrar:
> Found 1 modified file(s) in the pull request #1164.
> tools/common/StaticRegistrar.cs
> Enabled 'mtouch' tests because the modified file 'tools/common/StaticRegistrar.cs' matches prefix 'tools/common'
> Enabled 'mmp' tests because the modified file 'tools/common/StaticRegistrar.cs' matches prefix 'tools/common'
> Found 2 label(s) in the pull request #1164: cla-already-signed, run-mmp-tests
> Enabled 'mmp' tests because the label 'run-mmp-tests' is set.
This reverts commit abb0449b6c.
_Seriously_ this time. Here's the story:
- TouchBar support was breaking tests in master, even after my static
registrar fix in 6422000c27
- However, the fix wasn't broad enough, because the TouchBar APIs were
in Xcode 8.1 as well.
- Confusion on my end (You need latest macOS but not latest Xcode) and
confusion on others (since there were changes in Xcode 8.2 to touchbar,
but they were subtractive, caused us to think this needed to go in
Xcode 8.2
Convert MT1016 and MT1017 to newer test syntax, and at the same time change
them to not disable the managed linker.
For these tests it doesn't matter if they're linked or not, but linking is
much faster (20s vs 82s for both tests).
In 7c6d04f1 the code to create the NOTICE file was simplified, and the new
implementation is writing to a temporary file and then replacing the existing
file.
This makes the scenario that MT1017 was testing (failure if a readonly NOTICE
file already exists) go away, since we don't write to the existing file
anymore (so the build succeeds).
- https://bugzilla.xamarin.com/show_bug.cgi?id=46508
Since we were previously looking for the .exe instead of the launcher, mmp
failures would come back as good and we wouldn't rebuild. What we want
to do is look for the native launcher, which we perviously were doing wrong.
Store strings in the exception data when converting CFError to CFException, to
make sure the data stored is serializable (which is apparently a requirement
with the reference sources).
https://bugzilla.xamarin.com/show_bug.cgi?id=46626
The old `legacy` option will now be reported as a warning.
That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE).
This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls
Note: The BCL changes will happen in later stages.
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.
So make it a warning instead (and document what the user has to do to fix the
warning).
https://bugzilla.xamarin.com/show_bug.cgi?id=46552
This makes us only put packages in one directory (saves disk space and time),
and it also makes project files in multiple solutions work properly
(mtouch.csproj is in tests/tests.sln and tests/mtouch/mtouch.sln).
Considering the following binding code:
public enum HMAccessoryCategoryType {
[Field ("HMAccessoryCategoryTypeGarageDoorOpener")]
DoorOpener,
GarageDoorOpener = DoorOpener,
}
We must
1. Ensure that `HMAccessoryCategoryType.DoorOpener.GetConstant () ==
HMAccessoryCategoryType.GarageDoorOpener.GetConstant ()`;
This is done by using the numeric value of the enum member (instead of the name)
2. Ensure that `HMAccessoryCategoryTypeExtensions.GetValue ("HMAccessoryCategoryTypeGarageDoorOpener")`
always return the same enum value, i.e. it can **not** change between
XI versions (e.g. due to reflection ordering) as it could break
comparison code;
This is done by only adding a map to the member that has a [Field] and
means that:
2.1. the _favorite_ enum member should be the one with the [Field]; and
2.2. a [Field] value can only be used once per enum (or else we report
an BI1046 error). This also solve the duplicate code generation for
the constant loading code;
Reference:
* https://bugzilla.xamarin.com/show_bug.cgi?id=46285
Use metadata tokens instead of strings to find types and methods.
This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.
Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).
| | Before | After | Diff |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit | 102.810.144 | 102.609.456 | -200.688 = -0,20% |
| dontlink/64bit | 107.420.576 | 107.221.792 | -198.784 = -0,19% |
| linksdk/32bit | 40.957.296 | 40.936.864 | -20.432 = -0,05% |
| linksdk/64bit | 43.113.136 | 43.093.936 | -19.200 = -0,04% |
| linkall/32bit | 38.410.032 | 38.348.288 | -61.744 = -0,16% |
| linkall/64bit | 40.315.200 | 40.267.344 | -47.856 = -0,12% |
Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.
This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.
For a non-linked test app I get the following using the Xamarin profiler:
| | Before | After | Diff |
|-------------------|--------:|--------:|----------------:|
| Memory allocated | 2,8 MB | 2,4 MB | -0,4 MB = -14 % |
| Objects allocated | 43678 | 38463 | -5215 = -12 % |
| Private bytes | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.
The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.
E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites
mtouch (before)
Total time: 64202 ms
mtouch (after)
Total time: 34840 ms
* Add XM support for RemoveUserResourcesSubStep
* Tests supplied by @chamons
Update mdb files even if the corresponding assembly didn't change, because the
mdb can change even if the assembly didn't (if whitespace was modified in the
source code, causing code lines to move).
https://bugzilla.xamarin.com/show_bug.cgi?id=39535
Native libraries are already linked into the dylib for the binding assembly,
which means that if we also link it into the main executable, the native code
ends up twice in the app (which is bad for many reasons).
https://bugzilla.xamarin.com/show_bug.cgi?id=42473
Rolf Bjarne Kvinge
Timothy Risi
Manuel de la Pena
Chris Hamons
Sebastien Pouliot
Alex Soto