Context: https://github.com/xamarin/xamarin-android/pull/1211#issuecomment-359177901
Context: https://github.com/xamarin/xamarin-android/pull/1211#issuecomment-359179075
What *should* happen when a portion of a build fails?
That's not entirely rhetorical: the *entire* build should fail.
What *does* happen when a portion of a build fails?
Unfortunately that's also not rhetorical: the build continues!
(Say what?!)
Case in point: [PR #1211 build 2373][pr-2373], which experienced a
failure in the mono build:
[pr-2373]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/2373/
MONO_PATH="./../../class/lib/build:$MONO_PATH" ... -R ../../../class/lib/monodroid/nunitlite.dll ...
error CS0009: Metadata file '/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/external/mono/mcs/class/lib/monodroid/nunitlite.dll' could not be opened -- PE image doesn't contain managed metadata.
*But the error was ignored*, and the build continued, resulting in the
"final" errors (among others)
System.Net/NetworkChangeTest.cs(5,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference?
**This is *madness*.** The first error *should* have stopped the
build. The build *wasn't* stopped, meaning that it continued -- with
an "unstable" tree state -- resulting in "bizarre" build errors
*later*. In particular, `Xamarin.Android.NUniteLite.dll` wasn't built
in the *Debug* configuration because the *mono* build failed for the
Debug configuration, but everything "worked" in Release.
The fundamental cause of this madness? Makefile rules such as
`make leeroy-all`, which *effectively* are:
tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Debug ; \
tools/scripts/xabuild Xamarin.Android.sln /p:Configuration=Release; \
*Because* of the `;` separating the commands, any errors from the
first command are *ignored*, resulting in the tearing out of my hair
when everything goes "weird".
Review the Makefile targets in `Makefile` and
`build-tools/scripts/BuildEverything.mk` and replace `;` with
`|| exit 1` when the command should have fatal errors. This *should*
cause the build to fail the *first* time an error is encountered,
instead of continuing on its merry way to die horribly later.
Update the `make prepare` step so that we pass `JI_MAX_JDK=8` to
Java.Interop's `make prepare` step. This prevents us from using JDK 9
if it is installed on the machine.
Internal VSTS builds are failing *seemingly* because JDK 9 is
installed and used by default on the build machine, with `gradelw`
bailing out with:
Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
This previously worked with JDK 8, so we're hoping that the use of
JDK 9 is the cause, and by *excluding* JDK 9 from being used we'll be
able to build on VSTS again.
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60901
The root cause of the bug is the condition in build-tools/libzip/libzip.props
which checks whether to build libzip or not and, currently, does NOT build the
library only on Ubuntu machines. The reason for this was that, so far, none of
us tested the build on Debian and it wasn't certain what, if any, changes would
be required (despite Ubuntu being based on Debian) in order for the build to
work on Debian proper and, possibly, other related distros.
This commit introduces a new msbuild property, `$(HostOsFlavor)` which can be
used to cluster related distros/operating systems into groups with the purpose
of sharing certain behaviors or operations - like building, or not, of libzip.
This commit also introduces a `make prepare` script to install dependencies on
Debian (tested on Debian 9.1.2 64-bit) as well as rearranges the order in which
we check for distro-specific prepration script. We now first seek for script
specific to the current distro version/release and only then for the "generic"
script for this distribution.
With the changes in place `make prepare && make` work start-to-finish on Debian.
This basically implements the steps described in
Documentation/DevelopmentTips.md for the runtime and BCL assembles. Short help
is available by running
make rebuild-help
The end goal here is to enable Windows users to easily run the various
types of tests. Commands have been migrated to MSBuild, keeping `make`
commands the same for macOS and linux.
~~ Usage ~~
Windows:
```
msbuild Xamarin.Android.sln /t:RunAllTests
msbuild Xamarin.Android.sln /t:RunNUnitTests
msbuild Xamarin.Android.sln /t:RunJavaInteropTests
msbuild Xamarin.Android.sln /t:RunApkTests
```
macOS/linux should remain unchanged:
```
make run-all-tests
make run-nunit-tests
make run-ji-tests
make run-apk-tests
```
~~ Changes ~~
- Added a new `build-tools/scripts/RunTests.targets`
- `Before.Xamarin.Android.sln.targets` includes these test targets
- A new `<SetEnvironmentVariable/>` task is needed, added to
`xa-prep-tasks`
- Ported any environment variables set in Makefile to MSBuild
- `Mono.Android-Tests.csproj` needs to remove the `@(ProjectReference)`
within `xa-prep-tasks`:
- Otherwise `xa-prep-tasks.dll` can become locked on Windows
- A nested `xabuild.exe` call will attempt to overwrite it
- Update `.gitignore` for `*.rawproto` and the generated
`Xamarin.Android.Common.props`
I have been told that the `prepare-image-dependencies.sh` script
should also install `mono`, to ensure that the required mono exists.
Add a `@PKG_URLS@` variable to `prepare-image-dependencies.sh.in` to
support downloading and installing our minimum specified mono version.
Additionally, I discovered that `xbuild` bugs are still around; I just
keep forgetting their specifics. Case in point:
[Jenkins build #712][xa712] uploaded
[`prepare-image-dependencies.sh`][sh], and it's not good:
[xa712]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/
[sh]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/712/Azure/processDownloadRequest/xamarin-android/prepare-image-dependencies.shhttps://dl.google.com/android/repository/build-tools_r26.0.1-macosx.zip sdk/build-tools\$(XABuildToolsFolder)
...
https://dl.google.com/android/repository/android-15_r03.zip sdk/platforms\android-15
MSBuild properties contained within item metadata -- specifically
`%(AndroidSdkItem.DestDir)` -- aren't fully expanded, resulting in the
above value of `$(XABuildToolsFolder)`, which *should* be `26.0.1`.
Similarly, some install paths are using `\` (backslash) when they
should contain `/` (forward slash).
Jenkins has been updated to explicitly use `msbuild`:
$ make prepare-image-dependencies MSBUILD=msbuild
However, `\r` characters now appear in
`prepare-image-dependencies.sh`. Fix this by having the
`PrepareImageDependencies` target emit the MSBuild-generated file into
an intermediate file, then fix it up using **tr**(1).
Finally, correct the `brew install` command so that any errors are
ignored, for if a brew package is already installed, re-installing it
will result in an error.
We are investigating building Xamarin.Android atop
Visual Studio Team System (VSTS) in addition to our current Jenkins
setup, and one of the issues we're running into is "bootstrapping":
VSTS is configured to create a "fresh" VM for each build.
**Pro**: It should allow builds to be more reliable, as previous build
artifacts won't be present, and thus won't cause/hide errors.
**Con**: *Previous build artifacts are not present*. Previous build
artifacts such as *downloading and extracting* the Android NDK & SDK,
using `brew` to install dependencies, building MXE...
Ensuring that the dependencies are installed through `make prepare`
can be quite time consuming. What we want is a way to ensure that the
"build image" -- *what's already installed* when the VM boots --
contains all of our desired dependencies.
Furthermore, we *don't* want to have the responsible parties checkout
and build xamarin-android in order to determine what the dependencies
should be.
Attempt to square this circle by adding a new
`make prepare-image-dependencies` target, which processes
`@(AndroidSdkItem)`, `@(AndroidNdkItem)`, `@(AntItem)`, and
`@(RequiredProgram)` to create a `prepare-image-dependencies.sh`
script which will download and install the required dependencies.
The generated shell script does *not* take the state of the machine
running `make prepare-image-dependencies` into consideration. This
allows the target to be executed on one machine, and the output run
on another.
$ make prepare-image-dependencies
# creates `prepare-image-dependencies.sh`
*Note*: `make prepare-image-dependencies` does not currently deal
with MXE. (Building MXE on the VSTS VM is *very* time consuming, so
it's something we need to take care of. It is not *yet* dealt with.)
Context: https://github.com/nunit/nunit/releases/tag/3.7.1
Context: commit 6687dac5
The release notes for NUnit 3.7.1 mention a hang with parallelized
tests, so it is worth a try to see if updating fixes it the hangs
that we experienced and tried to workaround in 6687dac.
The `Xamarin.Android.Build.Tests` NUnit tests recently started
hanging after the tests were done.
Run tests with a single worker as a workaround until we figure out
why, unblocking Jenkins.
Context: 8643ded9
Context: 286b9c28
Context: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/700/testReport/
`Xamarin.ProjectTools` was updated in commit 8643ded9 to use `msbuild`
(via `xabuild`) *by default*, and commit 286b9c28 updated
`Xamarin.ProjectTools` to further use `msbuild`/`xabuild` when the
`$USE_MSBUILD` environment variable is *not* `0`, and to continue
using `xbuild` when `$USE_MSBUILD` is `0`.
Meaning before 8643ded9 `xbuild` was used for
`Xamarin.Android.Build.Tests` execution, and afterward `msbuild`
was used. (This change wasn't explicitly clear to some.)
"Revert" this behavior; use `xbuild` *by default* for
`Xamarin.Android.Build.Tests` execution, by updating the
`RUN_NUNIT_TEST` make `define` so that the `$USE_MSBUILD`
environment variable is exported to the *value of* the
`$(USE_MSBUILD)` make variable, IFF it's not the empty string.
If `$(USE_MSBUILD)` *is* the empty string, export `USE_MSBUILD=0`,
which will cause `xbuild` to be used.
What his means is that a default unit test invocation:
make run-all-tests
will use `xbuild` to run `Xamarin.Android.Build.Tests`. However,
if `msbuild` is *explicitly opted into*, then `msbuild` is used:
$ make run-all-tests MSBUILD=msbuild
# -or-
$ make run-all-tests MSBUILD=some/path/to/msbuild USE_MSBUILD=1
Furthermore, if/when we change the default MSBuild engine to
`msbuild` in the future -- by altering
`build-tools/scripts/msbuild.mk` to set `MSBUILD=msbuild` and
`USE_MSBUILD=1` by default -- then `make run-all-tests` will
*implicitly* follow suit.
With luck, "reverting" to `xbuild` use will allow the
[current `Xamarin.Android.Build.Tests` failures][xa700t] -- all 20 of
them -- to be "fixed" until such time as all
`Xamarin.Android.Build.Tests` tests *actually* pass with `msbuild`.
[xa700t]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/700/testReport/
When working with the `Makefile` I noticed this command doesn’t run the
tests:
```
$ make run-nunit-tests
make: Nothing to be done for `run-nunit-tests’.
```
And this command runs the tests:
```
$ make run-nunit-tests SKIP_NUNIT_TESTS=1
```
I suspect the intention is that `ifneq` needs to be `ifeq`.
@clancey was trying to build xamarin-android, which failed:
$ make prepare
./build-tools/scripts/generate-os-info Configuration.OperatingSystem.props
xbuild /p:Configuration=Debug /p:_DebugFileExt=.pdb build-tools/dependencies/dependencies.mdproj
...
warning : Referenced Project ../../external/xamarin-android-tools/src/Xamarin.Android.Tools.AndroidSdk/Xamarin.Android.Tools.AndroidSdk.csproj not found, ignoring.
...
Xamarin.Android.BuildTools.PrepTasks/JdkInfo.cs(9,23): error CS0234: The type or namespace name 'Tools' does not exist in the namespace 'Xamarin.Android' (are you missing an assembly reference?)
The problem is that `make prepare-deps`, which builds
`build-tools/dependencies/dependencies.mdproj`, implicitly builds
`build-tools/xa-prep-tasks/xa-prep-tasks.csproj`, which in turn
depends on
`external/xamarin-android-tools/src/Xamarin.Android.Tools.AndroidSdk/Xamarin.Android.Tools.AndroidSdk.csproj`,
which is only reliably created by `make prepare-external`s
`git submodule update --init --recursive`.
Unfortunately, `make prepare-external` wasn't invoked until *after*
`make prepare-deps`, meaning there is no way for `make prepare` to
actually work on a clean install!
(This works on Jenkins because Jenkins automatically checks out all
submodules, so it never encounters this "clean checkout" scenario.)
Reorder the targets that `make prepare` executes so that
`make prepare-external` is run *before* `make prepare-deps`, ensuring
that git submodules exist before we attempt to use them.
Context: 0077d151
Context: d1d9820a
A "funny" thing happened when commit e9daf5ea didn't build on Jenkins:
I realized that not all tests were run in all configurations. From
commit d1d9820a:
> Why are some tests Debug-only and some aren't?
The answer: time, primarily. Why run tests multiple times, when they
can be potentially time-consuming?
While tests can be slow, they're not always *that* slow -- except for
`Xamarin.Android.Build.Tests` and the BCL tests -- and even there,
program behavior can alter between Debug and Release configurations.
See in particular commit 0077d151, in which the BCL tests are run only
in the Debug configuration because tests *failed* when run in the
Release configuration.
The desire, then, is to run *all* tests in both Debug and Release
configurations. Yes, it'll take longer! So what! (Within reason:
`Xamarin.Android.Build.Tests` should only be run once!)
However, this raises two problems:
1. Filename collisions
2. Jenkins unit test display
Until now, all tests wrote files into a filename that didn't include
the Configuration, e.g. `TestResult-Mono.Android_Tests.xml`. If we did
run these tests twice, the second test invocation would overwrite the
first test invocation. This isn't desirable.
Then there's the display on Jenkins: if we did have e.g.
`TestResult-Mono.Android_Tests-Debug.xml` and
`TestResult-Mono.Android_Tests-Release.xml`, how will Jenkins display
that information? I haven't tested, but I would assume that one of two
things will occur, assuming reasonable Jenkins behavior:
1. Each test will be listed twice, e.g.
ApplicationContextIsApp
ApplicationContextIsApp
2. They'll be "merged" into a single entry.
Neither of these behaviors is desirable: if Debug passes but Release
fails, we need to be able to differentiate between them. Neither of
these possible renderings allows us to tell which configuration fails.
Solve both of these problems by introducing a new `<RenameTestCases/>`
task. This task takes three values of importance:
```xml
<RenameTestCases
Configuration="CONFIGURATION"
SourceFile="SOURCE"
DestinationFolder="DESTINATION"
/>
```
The `<RenameTestCases/>` task will read in `SOURCE`, and if `SOURCE`
is an XML file which we determine is NUnit2-formatted XML (root
element of `<test-case/>`), we will update every `//test-case/@name`
value so that it ends with ` / CONFIGURATION`. The updated XML is
then written to the `DESTINATION` directory, with a filename that
contains `CONFIGURATION`, and `SOURCE` is deleted.
Thus, if we have a Debug-configuration
`TestResult-Mono.Android_Tests.xml` file with XML fragment:
```xml
<test-case
name="Mono.Android_Tests, Android.AppTests.ApplicationTest.ApplicationContextIsApp"
...
/>
```
then `<RenameTestCases/>` will create the file
`TestResult-Mono.Android_Tests-Debug.xml` file with XML fragment:
```xml
<test-case
name="Mono.Android_Tests, Android.AppTests.ApplicationTest.ApplicationContextIsApp / Debug"
...
/>
```
This allows us to run tests in both Debug and Release configurations
while not inadvertently overwriting the `TestResults*.xml` files that
Jenkins reads, and ensuring that the Jenkins test result output is
rendered in a meaningfully useful fashion.
Aside: when updating `//test-case/@name`, the resulting value *cannot*
end in `)`. If it does, then the `(root)` package name issue fixed in
commit 23b2642e reappears for the `generator` unit tests.
**Completely random aside about the state of `xbuild`**:
A development version of `<RenameTestCases/>` was "saner", using
`ITaskItem[]` and not string:
```csharp
partial class RenameTestCases {
public ITaskItem[] SourceFiles {get; set;}
// vs.
// public string SourceFile {get; set;}
}
```
The problem is that the above, while entirely reasonable, did not work
at all correctly with `xbuild`:
```xml
<RenameTestCases SourceFiles="%(TestApk.ResultsPath)" />
```
Under `xbuild`, MSBuild properties would not be expanded, e.g.
`RenameTestCases.SourceFiles` would get a "bizarro" value of e.g.
`$(OutputPath)Mono.Android_Tests-Signed.apk`, which is *useless* and
would result in `FileNotFoundException`s.
MSBuild proper, of course, worked as desired.
TODO: Once this is merged, update the Jenkins Configuration page so
that instead of:
make run-all-tests V=1 || exit 1
it instead runs both Debug and Release configuration tests:
make run-all-tests SKIP_NUNIT_TESTS=1 V=1 || exit 1
make run-all-tests CONFIGURATION=Release V=1 || exit 1
Note that `$(SKIP_NUNIT_TESTS)` is specified so that we only run the
lengthy (1+hr!) `Xamarin.Android.Build.Tests` tests in the Release
configuration, not the Debug + Release configurations.
Commit d1d9820a enabled `Xamarin.Android.Bcl-Tests` to build and run
in the Release configuration. This was the right idea, but the wrong
time: [The Jenkins build for xamarin-android/d0d8640b][xad0] reports
68 failures, due to running the `Xamarin.Android.Bcl-Tests` in the
Release configuration, in which the linker is *enabled*.
[xad0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/666/
Enabling the linker is breaking these tests. :-(
This needs to be addressed -- enabling the linker should *not* break
the BCL unit tests! -- but in the meantime, partially revert commit
d1d9820a and only run the BCL unit tests in the Debug configuration,
removing this source of unit test failures.
The [Jenkins `xamarin-android` build][xae9] for commit e9daf5ea was
unexpectedly UNSTABLE, because an error was encountered:
[xae9]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/662/
Tool …/adb execution started with arguments: -s emulator-5570 install "…/xamarin-android/tests/../bin/TestRelease/Xamarin.Android.Bcl_Tests-Signed.apk"
adb: error: cannot stat '…/xamarin-android/tests/../bin/TestRelease/Xamarin.Android.Bcl_Tests-Signed.apk':
No such file or directory
The error was encountered because `tests/Xamarin.Android.Bcl-Tests`
wasn't built for the Release configuration, because it wasn't part of
`$(TEST_APK_PROJECTS_RELEASE)` within `Makefile`.
This raises an interesting question: what is the best solution?
1. Make `Xamarin.Android.Bcl-Tests` a Debug-only unit test.
2. Build and run `Xamarin.Android.Bcl-Tests` in both Debug & Release.
...quickly followed by a *second* question:
Why are some tests Debug-only and some aren't?
I don't have a good handle on this second question, other than that it
would "duplicate" unit test execution, thus lengthening build times.
However, I'm not convinced that's a good rationale, either: the
Release runtime has optimizations (`-O0 -fno-omit-frame-pointer` Debug
vs. `-O2` Release), which could theoretically break a great many
things. The Release runtime is also what is used in our commercial
products; the Debug runtime is largely only useful for #runtime
debugging.
We thus should want as many tests as possible to run in Release, not
as few as possible
This allows us to tentatively answer the first question: we should add
`Xamarin.Android.Bcl-Tests` to `$(TEST_APK_PROJECTS_RELEASE)` so that
it's run in *both* Debug *and* Release configurations. This in turn
will ensure that the failing `adb install` command succeeds, which
*should* allow the build to PASS, as desired.
What do we want? (with apologies to 48e3fc26)
**MOAR** Unit tests!
Specifically, we want to run the BCL unit tests which mono generates:
$ cd external/mono/mcs/class/corlib
$ make PROFILE=monodroid test
# creates `monodroid_corlib_test.dll`
Creation of `monodroid_*_test.dll` assemblies and the
`make PROFILE=monodroid test` target is a relatively recent
development, for which I need to buy the #runtime team some beers.
In terms of `mono-runtimes.targets`, we can build *all* of the BCL
unit test assemblies with:
$ cd external/mono/mcs/class
$ make -i do-test PROFILE=monodroid
Now that we can create them, how do we *use* them? That's the trickier
bit: they need to be built within mono, as part of the existing BCL
build process. This in turn means that the BCL unit test assemblies
need to be distributed as part of the mono bundle, as we don't want to
rebuild the mono repo "from scratch" just for the unit tests.
Update `build-tools/mono-runtimes/ProfileAssemblies.projitems` to
include a new `@(MonoTestAssembly)` item group which contains all of
the BCL unit test assemblies and related files which should be
included into `bundle-*.zip`. Additionally, add
`ProfileAssemblies.projitems` to `@(VersionFile)` witihin
`bundle-path.targets`, so that if anything within
`ProfileAssemblies.projitems` changes, we rebuild the bundle.
Once we *have* the BCL unit test assemblies, and their dependencies,
we need to *run* them. The new `Xamarin.Android.Bcl-Tests.csproj`
project is a Xamarin.Android application project which will execute
the unit tests.
There's just one small problem: Xamarin.Android apps want to use
`Xamarin.Android.NUnitLite.dll`. The BCL unit test assemblies instead
build against their own `nunitlite.dll`, which has no Xamarin.Android
integration or support. How do we use the new test assemblies?
*Force* a fix by using `remap-assembly-ref` to "rename" the
`nunitlite` assembly reference to `Xamarin.Android.NUnitLite.dll`.
This *cannot* be done as part of the `mono-runtimes.mdproj` build, as
`Xamarin.Android.NUnitLite.dll` won't yet exist. Instead, remap the
assemblies within `Xamarin.Android.Bcl-Tests.targets`, and distribute
the remapped assemblies with the application.
Finally, address one other "small" problem: not all of the unit tests
pass! Some of these are for reasons we don't know, and others will
require changes to `mono`.
Update `Xamarin.Android.NUnitLite` to allow *filtering* of tests:
namespace Xamarin.Android.NUnitLite {
partial class TestSuiteActivity {
public ITestFilter Filter {get; set;}
public virtual void UpdateFilter ();
}
partial class TestSuiteInstrumentation {
public ITestFilter Filter {get; set;}
public virtual void UpdateFilter ();
}
}
`TestSuiteActivity.UpdateFilter()` is called by
`TestSuiteActivity.OnCreate()`, *after* `GetIncludedCategories()` and
`GetExcludedCategories()` are called, to allow subclasses to alter the
`ITestFilter` which is used to determine which tests are executed.
`TestSuiteInstrumentation.UpdateFilter()` is called by
`TestSuiteInstrumentation.OnStart()`, *after*
`GetIncludedCategories()` and `GetExcludedCategories()` are called, to
allow subclasses to alter the `ITestFilter` which is used to determine
which tests are executed.
`Xamarin.Android.Bcl_Tests` overrides both of these and updates the
`Filter` property so that "known failing" tests are excluded. This
allows us to skip failing tests, giving us time to properly fix them
in time while allowing the rest of this PR to be merged.
The skipped tests include:
* MonoTests.System.Reflection.AssemblyTest.GetReferencedAssemblies
* MonoTests.System.ServiceModel.Description.WebInvokeAttributeTest.RejectTwoParametersWhenNotWrapped
Upgrade to use NUnit 3.7, as this version supports running test
methods in parallel, not just test fixtures.
Add `[Parallelizable (ParallelScope.Children)]` where appropriate
so that tests *are* run in parallel. This cuts PR build times from
roughly 1h16min to 52min, a ~32% reduction in build times!
Fix tests so that they *can* be run in parallel. Many of the tests
were using the same folders, which causes problems when the tests are
run in parallel as the tests will conflict with each other --
one test might delete an entire directory causing another to fail.
Many of the tests also take parameters, we usually use
TestContext.CurrentContext.Test.Name
when we want to use the Test method as the name. However
with parameterized tests this can sometimes include invalid
characters for paths/filenames. So a new property has been
introduced in the `BaseTest` class `TestName` which cleans up
and removes problematic characters.
Update the `make run-nunit-tests` target so that it now takes a
`$(TEST)` variable, which allows running a specific test fixture
or method, not all tests:
make run-nunit-tests \
TEST=Xamarin.Android.Build.Tests.BuildTest.BuildBasicApplication \
NUNIT_TESTS=bin/TestDebug/Xamarin.Android.Build.Tests.dll
Context: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/1659/testReport/
I’ve been noticing the Xamarin.Android.Build.Tests are occasionally
failing and reporting zero test results (no failures, no success). This
situation doesn’t break PR builds, and effectively skips
Xamarin.Android.Build.Tests.
Updating NUnit.ConsoleRunner may be the fix as mentioned on this issue:
https://github.com/nunit/nunit/issues/1509
Unfortunately NUnit has some more dependencies now, so there are a few
more packages. I chose version 3.6.0, as I could get a parallel version
number across all NUnit packages.
There is some code which is conceptually, if not literally, duplicated
between the xamarin-android and the IDEs (Visual Studio,
Visual Studio for Mac), in particular code that deals with finding the
Android SDK and Java JDK locations.
This code has been split out into a new `xamarin-android-tools` repo
to facilitate sharing, without the IDEs needing to submodule
xamarin-android, which is quite large.
Cleanup the xamarin-android repo to use the new xamarin-android-tools
repo for Android SDK information/etc.
This reverts commit ae2791a1d7.
The PR was intended just for testing on Jenkins PR builder. Was
labeled `do-not-merge`. I should probably state it in the commit
message as well next time, to be better visible.
Commit 53631f2 tried to fix build/run of our forms test. It added its
proj to the TEST_APK_PROJECTS list. Because forms test is used
conditionaly only in the Release configuration, it needs to be
actually added to the TEST_APK_PROJECTS_RELEASE list instead. Noted
the release list in the RunApkTests.targets file.
Also do not run the forms test in Release/Aot so that we don't have
the times measurements in the .csv ouput file twice
[Jenkins build 601][j601] is unstable:
[j601]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/601/
xamarin-android/build-tools/scripts/TestApks.targets: error : Tool exited with code: 255.
Output: adb: error: cannot stat '…/xamarin-android/tests/../bin/TestRelease/Xamarin.Forms_Performance_Integration-Signed.apk':
No such file or directory
`Xamarin.Forms_Performance_Integration-Signed.apk` doesn't exist
because it's not built, and it's not built because commit
09ba1ee4 forgot to add the project to `$(TEST_APK_PROJECTS)` within
`Makefile`. (Oops.)
Update `$(TEST_APK_PROJECTS)` so that
`Xamarin.Forms.Performance.Integration.Droid.csproj` is built.
Commit 498cacd2 had the right idea, but the wrong implementation.
(The perils of doing things in a rush to prepare for branching!)
Specifically, it used `$(CONFIGURATION)` when it *should* have used
`$(conf)`, the variable introduced by:
$(foreach conf, $(CONFIGURATIONS),
# Need to use `$(conf)` here, *not* `$(CONFIGURATION)`!
)
`$(CONFIGURATION)` is Debug (by default), while on Jenkins
`$(CONFIGURATIONS)` is "Debug Release". Consequently, Java.Interop did
*not* have `make prepare CONFIGURATION=Release`/etc. run, which means
that `external/Java.Interop/bin/BuildRelease/JdkInfo.props` didn't
exist, which means [the build broke in `src/monodroid`][0]:
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/598/
xamarin-android/src/monodroid/monodroid.mdproj: error : …/xamarin-android/src/monodroid/monodroid.mdproj:
monodroid.targets: Project file could not be imported, it was being imported by …/xamarin-android/src/monodroid/monodroid.mdproj:
…/xamarin-android/src/monodroid/monodroid.targets could not import "..\..\external\Java.Interop\bin\Build$(Configuration)\JdkInfo.props"
where `$(Configuration)` was Release.
Fix `make prepare-external` to properly use `$(conf)` instead of
`$(CONFIGURATION)` so that Java.Interop is configured for all
`$(CONFIGURATIONS)` values, which will allow `src/monodroid` to build.
[Java.Interop/7d9d72a5][ji7], pulled in via 59518692, has an
interesting semantic change: when building the Release configuration:
# Assume a clean build tree...
make prepare all CONFIGURATIONS=Release
Java.Interop now requires that
`external/Java.Interop/bin/BuildRelease/JdkInfo.props` exist.
(*Previously*, the Release configuration would use the
`…/BuildDebug/JdkInfo.props` file.)
Unfortunately, xamarin-android wasn't updated accordingly. As such, if
*only* the Release configuration is built -- not Debug *and* Release,
as Jenkins does -- then xamarin-android doesn't build:
xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop.csproj: error :
…/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop.csproj: Java.Interop.targets:
Project file could not be imported, it was being imported by …/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop.csproj:
…/xamarin-android/external/Java.Interop/src/Java.Interop/Java.Interop.targets
could not import "$(JNIEnvGenPath)\JdkInfo.props"
`$(JNIEnvGenPath)` is now `bin/Build$(Configuration)`, whereas before
it was always `bin/BuildDebug`, so the above error occurs because
`external/Java.Interop/bin/BuildRelease/JdkInfo.props` doesn't exist.
Fix the `make prepare` target so that *all* `$(CONFIGURATIONS)` values
are configured for Java.Interop, not just the Debug configuration.
This should allow Release-only builds to work.
[ji7]: 7d9d72a538
Commit 8e7d37bb is a sign of duplication: in order to use a
`Mono.Android.dll` binding assembly, not only do we need to *build*
the binding assembly, but we *also* need to update
`Xamarin.Android.Build.Utilities.dll` to "know" about the new binding
version (to map API level to `$(TargetFrameworkVersion)`).
Even "better" (worse), if the new API level is a *preview*, there is
no *consistent* API level. For example, with API-O, `android.jar`
isn't at
`$(AndroidSdkDirectory)\platforms\android-@API_LEVEL@\android.jar`,
where `@API_LEVEL@` is 26 (because various codepaths require that the
"api level" be an integer). Instead, it's installed at
`$(AndroidSdkDirectory)\platforms\android-O\android.jar`, where
`O` is the "id" of the preview API level.
This "id" is "leaky", in turn requiring that
`Xamarin.Android.Build.Tasks.dll` *also* be updated to deal with the
mappings.
Even "better" (worse), if we *forget* to cross all our our 't's and
dot all of our 'i's, we'll have a binding assembly which can't be
used. (Which is why we needed commit 8e7d37bb; without it, the API-O
binding can't be used!)
This is all obviously madness. ;-)
Clean this mess up:
1. Update `src/Mono.Android` to create a new `AndroidApiInfo.xml`
file within the `$(TargetFrameworkVersion)` directory.
This will contain all the information needed to map Android API
levels to Ids and Android OS versions and
`$(TargetFrameworkVersion)` values.
```xml
<AndroidApiInfo>
<Id>10</Id>
<Level>10</Level>
<Name>Gingerbread</Name>
<Version>v2.3</Version>
</AndroidApiInfo>
```
2. Add a new `Xamarin.Android.Build.Utilities.AndroidVersions` type
which looks for and parses these new `AndroidApiInfo.xml` files.
3. Fixup all the other places using `AndroidVersion.KnownVersions`
and related members to instead use `AndroidVersions`.
4. Remove all the old APIs which rely on hardcoded data.
The advantage to all this is that we can support new API level
bindings by just building a new `Mono.Android.dll` and placing an
`AndroidApiInfo.xml` into the appropriate location (next to
`Mono.Android.dll`). No further code changes would be required.
Related: The build system still has a nasy habit of using system-wide
directories to resolve files we'd really rather it not, e.g. in
[xamarin-android/master build #503][m503]:
[m503]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/503/consoleText
Building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj" ("/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets"); "_SetLatestTargetFrameworkVersion" depends on it.
Target _GetReferenceAssemblyPaths:
Task "GetReferenceAssemblyPaths"
Using task GetReferenceAssemblyPaths from Microsoft.Build.Tasks.GetReferenceAssemblyPaths, Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Looking for framework 'MonoAndroid,Version=v1.0' in root path '/Library/Frameworks/Mono.framework/External/xbuild-frameworks'
Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'
Done executing task "GetReferenceAssemblyPaths"
Done building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj".
Done building target "_GetReferenceAssemblyPaths" in project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj" ("/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets"); "_SetLatestTargetFrameworkVersion" depends on it.
Target _SetLatestTargetFrameworkVersion:
Task "ResolveSdks"
ReferenceAssemblyPaths:
/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/
Note the use of the path
`/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0`.
This *was* "fine" -- if undesirable -- but with the introduction of
`AndroidVersions` and `AndroidApiInfo.xml` files within the frameworks
directory, everything falls apart, becuase the system install
*does not have* the `AndroidApiInfo.xml` files, so
*NO API LEVELS ARE FOUND*.
Oops.
The only way to fix this is to use `$XBUILD_FRAMEWORK_FOLDERS_PATH`,
and the sanest way to do *that* is to use `tools/scripts/xabuild` for
the primary build.
Unfortunately, using `xabuild` for the primary build breaks the
`msbuild`-based build, as it can't resolve the
`.NETFramework,Version=v4.6.1` framework.
Context: https://github.com/xamarin/xamarin-android/pull/599#issuecomment-319801330
Split the difference here by introducing `$(_SLN_BUILD)`: use
`xabuild` when building with `xbuild`, and continue using `msbuild`
when building with `msbuild`.
- besides running in different configurations than default (Debug),
we will also use the startup times measurements in the Jenkins
plots
- also fixes a typo in `RunApkTests.targets`, where supposedly
`Condition` was used in place of `Configuration`
- modifies logcat timing file names, so that it is based on test
results filename instead of just package name. that way we can have
multiple timing results for the same test with various
configurations
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=57342
The investigation in the bug suggests that we are picking up a
reference assembly rather than a the actual implementation.
This is to do with the way netstandard nuget packages work, they
include both `ref` and `lib` folders.
In this case `ref` was being included in the package rather than
`lib`. This commit alters the `_ResolveAssemblies` to use
@(ReferenceCopyLocalPaths)
This ItemGroup is populated with the correct items.
Context: https://github.com/xamarin/xamarin-android/pull/253#discussion_r82862993
The *intention* is that Jenkins-produced `oss-xamarin.android*.zip`
artifacts be usable on Windows, so that side-by-side testing can be
performed without replacing the system installation. Usage is in
[UsingJenkinsBuildArtifacts.md](Documentation/UsingJenkinsBuildArtifacts).
This isn't *entirely* the case. It was *apparently* the case at the
time of commit 87ca2737, but things have bitrotten since. For
example, following the 87ca2737 instructions would currently result
in an XA0020 `Could not find monodroid` error, because
`class-parse.exe` wasn't where Windows expects it to be (it was in
`lib/mandroid`, not `lib/xbuild/Xamarin/Android`).
This needs to be fixed.
Additionally, PR #253 mentions that, for filesystem organization, it
would be useful if the macOS/Linux directory structure --
`$prefix/bin`, `$prefix/lib/mandroid`,
`$prefix/lib/xbuild/Xamarin/Android`, `$prefix/lib/xbuild-frameworks`
-- more closely resembled the Windows directory structure of
`$MSBuild` and `$ReferenceAssemblies` (as seen in `.vsix` files).
This would turn macOS/Linux into using `$xa_prefix/xbuild` and
`$xa_prefix/xbuild-frameworks` directories.
`$prefix/bin` would only contain `xabuild`. What is currently in
`$prefix/lib/mandroid` would be merged with
`$xa_prefix/xbuild/Xamarin/Android`.
`$xa_prefix` would `$prefix/lib/xamarin.android`.
This would turn the current macOS structure:
$prefix/bin/xabuild
$prefix/bin/generator
$prefix/bin/cross-arm
$prefix/lib/mandroid/generator.exe
$prefix/lib/xbuild-frameworks/MonoAndroid/v1.0/mscorlib.dll
$prefix/lib/xbuild/Xamarin/Android/Xamarin.Android.Common.targets
Into:
$prefix/bin/xabuild
$prefix/lib/xamarin.android/xbuild-frameworks/MonoAndroid/v1.0/mscorlib.dll
$prefix/lib/xamarin.android/xbuild/Xamarin/Android/generator.exe
$prefix/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets
$prefix/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/cross-arm
Other notes:
* The `bundle-*.zip` filename has been has been changed to include a
*hash* of the contents of various files, in particular
`build-tools\mono-runtimes.*`. This was instigated via a
conversation with @kumpera about making the filename more
"idiot-proof": `mono-runtimes.props` contains *compiler flags*,
and if any of those change, then *logically* the bundle should
differ as well, as the mono runtimes may differ in significant
ways. In theory, the `-vXX` version should be used to track this,
but this is a manual change, easy to overlook. The new `-hHASH`
part of the filename should be more automagic.
The new `<HashFileContents/>` task in `xa-prep-tasks.dll` is
responsible for creating the hash value.
* `Configuration.Java.Interop.Override.props` was moved into
`build-tools/scripts`, because that would cleanup the root
directory a bit.
* OS-specific binaries are now placed into
`$prefix/lib/xamarin.android/xbuild/Xamarin/Android/$(HostOS)`.
On a theoretical plus side, this means that the same build
directory can contain OS-specific binaries for multiple operating
systems. (I don't know if anyone shares a build tree between e.g.
macOS and Linux, but if anyone *does*...)
Unfortunately this requires a workaround for an `xbuild` bug:
`%(_LlvmRuntime.InstallPath)` and
`%(_MonoCrossRuntime.InstallPath)` *cannot* use MSBuild
properties, e.g. `<InstallPath>$(HostOS)/</InstallPath>` doesn't
work as desired; it's instead treated literally.
Special-case `%(InstallPath)` until we fully migrate to MSBuild.
* `$(MonoAndroidToolsDirectory)` should be considered *dead*, along
with `$(MonoAndroidBinDirectory)`, as these should now *always*
be the same directory as where `Xamarin.Android.Build.Tasks.dll`
is located, or a `$(HostOS)` sub-directory.
* `Xamarin.ProjectTools.csproj` needed to be updated to ensure that
the build order was correct.
* Remove all `[Obsolete]` and unreferenced members from
`Xamarin.Android.Build.Utilities.dll`. There's too much in there,
and it makes my head hurt trying to understand the
interrelationships between it all. If it's not used, it's gone.
* The changes to `src/monodroid/jni/Android.mk` are...weird. The
removal of `-I$(topdir)/libmonodroid/zip`/etc. is to reduce use of
non-existent paths, as `$(topdir)` isn't defined, so that's
*actually* `-I/libmonodroid/zip`, which is nonsensical. So far,
so good. What's *odd* is the addition of `$(LOCAL_PATH)` to
`$(LOCAL_C_INCLUDES)`: This is needed so that
`external/mono/support/zlib-helper.c` exports `CreateZStream` and
related symbols, otherwise we get a unit test failure in
`GzipStreamTest.Compression` due to an
`EntryPointNotFoundException`, because `CreateZStream` isn't
exported/public.
What's odd here is that I don't understand what caused this
behavior to change. Previous builds exported `CreateZStream`,
otherwise the tests would fail, and I don't understand how any of
the other changes in this PR would be at fault, though that's
certainly the most plausible explanation.
Regardless, `-Ijni` *first* (due to adding `$(LOCAL_PATH)` to
`$(LOCAL_C_INCLUDES)`) is the desired behavior, so that
`jni/config.h` is included, thus ensuring that `MONO_API` has the
required definition when building `zlib-helper.c`.
Developers like API compatibility; it helps ensure that their
investment in our platform isn't a waste of time.
Add `tests/api-compatibility` and a new
`make run-api-compatibility-tests` target, part of
`make run-all-tests`, which compares the API of the assemblies in the
current build tree against a "known good" API description maintained
in `tests/api-compatibility/reference/*.xml.gz`, one `.xml.gz` file
per assembly that we are interested in.
The new [`xamarin-android-api-compatibility`][0] submodule contains
the current API description and Make targets to check and update the
API description. `xamarin-android-api-compatibility` uses the
utilities `mono-api-info` and `mono-api-html` to generate and compare
the API descriptions.
A submodule is used because the API descriptions can be quite large --
Mono.Android.xml is currently 54MB -- and we don't want the change
history on these files to "clog up" the xamarin-android repo.
[0]: https://github.com/xamarin/xamarin-android-api-compatibility
The `make install` target can be used on Unixy platforms to install
Xamarin.Android into a system-wide location. By default it installs
into a prefix of `/usr/local`:
make install
The prefix may be changed by overriding the `$(prefix)` make variable:
# Install system-wide
make install prefix=/usr
Installation is performed by copying the contents of
`bin/$(CONFIGURATION)` into `$(prefix)/lib/xamarin.android`.
Only `xabuild` is installed into `$(prefix)/bin` and (presumably)
accessible within `$PATH`.
Commit 8ebb9cb2 inadvertently made `make prepare` the default target
when running on Linux, instead of `make all`, breaking semantics:
$ make
# pre-8ebb9cb2, invoked `make all` everywhere.
# Invokes `make prepare` on Linux in 8ebb9cb2, but
# `make all` on macOS. Confusion!
Revert the default `make` target to `make all`.
Bump to LibZipSharp/master/1b217dab to increase reliability of
`libZipSharp.dll.config` creation on Linux if/when
`ldconfig -p | grep libzip` returns more than one shared library.
Add `make prepare` support for Arch Linux.
Re-factor the `make prepare` logic for Linux into a set of
`build-tools/scripts/dependencies/linux-prepare-*.sh` shell scripts,
so that instead of having every possible Linux distro combined into
`Makefile`, we can split them up in a more sensible manner.
Dependency scripts should have one of the names:
linux-prepare-$(LINUX_DISTRO).sh
linux-prepare-$(LINUX_DISTRO)-$(LINUX_DISTRO_RELEASE).sh
where `$(LINUX_DISTRO)` is from `lsb_release -i -s`, and
`$(LINUX_DISTRO_RELEASE)` is from `lsb_release -r -s`. The dependency
script should install all required dependencies to build the
xamarin-android repo, *unless* `$NO_SUDO` is set.
If the `$NO_SUDO` environment variable is `true`, then the dependency
script should check to see if all dependencies are installed. If
they are not installed, it should exit with a non-0 (zero) value.
If `$NO_SUDO` is `false`, then `sudo` should be used to install
the dependencies.
Adds support to build all of the LLVM-based cross compilers on Linux and
thus makes it possible to use AOT on Linux.
Windows cross compilers can be built as well, but build of libmonodroid
or libzip-windows won't work because Linux doesn't use mxe and mingw
packaged for Linux doesn't come with a handful of libraries required for
the above builds to complete (mman, dlfcn, cmake and friends)
Bump to Java.Interop/master/8d7060d1
Bump to cecil/master/5f93431f
We'd like to run the Java.Interop unit tests as part of the
xamarin-android `make run-all-tests` target, for two rasons:
1. An extra layer of sanity checking, and
2. Some of the Java.Interop tests require an Android SDK.
In particular, the
`ParameterFixupTests.XmlDeclaration_FixedUpFromDocumentation()` test
from `Xamarin.Android.Tools.Bytecode-Tests.dll` attempts to read
Android documentation from `$ANDROID_SDK_PATH` to test parameter name
fixups.
However, Java.Interop doesn't install -- and thus can't readily
require -- an Android SDK, meaning this test is never executed as part
of the Java.Interop Jenkins process.
That test *can* be readily executed in xamarin-android, as it *does*
install an Android SDK, and thus its presence can be assumed.
Add a new `make run-ji-tests` target which runs the Java.Interop unit
tests, copying their test output into the same directory that the
other `TestResult-*.xml` files are placed, so that Jenkins can pick
them up for display.
Within the `make run-ji-tests` target, export the `ANDROID_SDK_PATH`
environment variable so that *all* the
`Xamarin.Android.Tools.Bytecode-Tests.dll` tests can execute.
Which introduces two problems:
1. The `Xamarin.Android.Tools.Bytecode-Tests.dll` tests require that
`$ANDROID_SDK_PATH` contain documentation...which we're not
currently installing.
2. The Java.Interop tests still fail, due to parameter name changes,
as those tests were originally using API-18 docs.
Result: the `ParameterFixupTest` tests fail. :-(
Fix this conundrum by instaslling `docs-24_r01.zip` within
`$(AndroidSdkDirectory)`, allowing the tests to execute as intended,
and by updating to Java.Interop/master/8d7060d1, which updates the
expected parameter name output.
One of the problems with the jenkins build is the logs from the
failed tests are not available on the website. This commit makes
sure that any tests that did not pass have the build.log information
written to the TestContext.Out. On jenkins this is setup to
write to a file in the bin\Test$(Configuration) directory.
The Makefile has also been updated to write this information
to the output. This will allow the data to appear in the raw
output log.
The PR builder is wedged. It needs a specific mono, but it can't
install mono because `$(call GetPath,...)` returns a bad value [^1].
Run `make prepare-deps` *first*, so that we can install a proper mono
before we try anything else.
Additionally, use "chained dependencies" so that the `prepare-*`
targets are `make -j`-friendly.
Finally, because the `$(AutoProvision)` logic installs Mono 4.8 as a
baseline (by default), the [xamarin-android-msbuild][1] job is now
building with Mono 4.8, whereas previously it used Mono 4.6.
[This *appears* to have broken things][2], because the
`_GenerateFrameworkList` target in `src/Mono.Android` isn't being
executed when it should be, resulting in:
error MSB3644: The reference assemblies for framework "MonoAndroid,Version=v7.1" were not found.
Change the default "minimal" Mono macOS .pkg to Mono 4.6, as that's
"known good". Mono 4.8 support will be in a separate commit.
The #runtime team is requesting that Xamarin.Android support
"auto-provisioning": the ability to track dependency *versions*, and
if there is a "version mismatch", *install* a dependency that
satisfies the minimum.
The primary use case is Mono itself: there is a desire to build
xamarin-android *itself* against mono/master, to see what breaks.
(Does the C# compiler break things? Does the JIT hang? etc.)
Extend the existing `@(RequiredProgram)` infrastructure to attempt to
support this:
* `%(RequiredProgram.MinimumVersion)`: The minimum program version
that is supported.
* `%(RequiredProgram.MaximumVersion)`: The maximum program version
that is supported.
* `%(RequiredProgram.CurrentVersionCommand)`: A command to execute to
obtain the current program version.
Defaults to `%(RequiredProgram.Identity) --version`.
* `%(RequiredProgram.MinimumUrl)`: URL to download "something" to use
to obtain a version of the program that satisfies
`%(MinimumVersion)`.
* `%(RequiredProgram.Install)`: Command to execute which installs the
minimum version of the program.
`%(RequiredProgram.CurrentVersionCommand)`,
`%(RequiredProgram.MinimumUrl)`, and `%(RequiredProgram.Install)` can
all be "overridden" for platform-specific values by prefixing the
value with `$(HostOSName)` and/or `$(HostOS)`. Thus, macOS-specific
values can be stored into e.g. `%(RequiredProgram.DarwinMinimumUrl)`
and `%(RequiredProgram.DarwinInstall)`.
Auto-Provisioning is controlled by the new `$(AutoProvision)`
property, which can be provided in `Configuration.Override.props`.
It defaults to `False`.
If the `$(AutoProvisionUsesSudo)` MSBuild property is True, then
`sudo` is used to invoke all install commands.
Context: b1f1370896
Context: 452d405e32
Context: 9a50c668a4
Context: b89dc15d9b
The `xamarin-android` repo [can't be built with msbuild][0]:
src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj(348,3):
error MSB4019: The imported project ".../bin/Debug/lib/xbuild/Xamarin/Android/Xamarin.Android.CSharp.targets"
was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
...
src/Mono.Posix/Mono.Posix.csproj(236,3): error MSB4019: The imported
project ".../bin/Debug/lib/xbuild/Xamarin/Android/Xamarin.Android.CSharp.targets"
was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
...
src/Mono.Data.Sqlite/Mono.Data.Sqlite.csproj(183,3): error MSB4019:
The imported project ".../bin/Debug/lib/xbuild/Xamarin/Android/Xamarin.Android.CSharp.targets"
was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Plus various other similar and different errors.
This is a bit of a problem as I'd like to build everthing with
MSBuild, particularly with a view toward future/eventual IDE
integration, but if things don't build with MSBuild *at all*...
That's a bit of a pickle.
But first, about those above errors...what's going on?
The short version is that `xbuild` has a "feature" that `msbuild`
lacks, and it's a feature that has been inadvertently relied on:
`xbuild` loads projects lazily.
This requires elaboration. :-)
A "solution" is a graph of projects with various dependencies, as
specified by the `.sln` file and MSBuild `@(ProjectReference)` items.
Reading this graph requires parsing the e.g. `.csproj` files to read
the `@(ProjectReference)` items to construct the graph so that
projects can be built in the proper order.
This is where `xbuild` and `msbuild` appear to differ:
* `xbuild` appears to use a "normal" XML parser to read project files
when constructing the project graph.
* `msbuild` appears to "fully load" the project files into an internal
object instance for further processing.
The difference between these approaches is visible when a project file
`<Import/>`s a file...which doesn't (yet!) exist.
Case in point: `Mono.Posix.csproj` needs to be a "normal"
Xamarin.Android project file, using the normal Xamarin.Android build
process, so that Android native libraries can be embedded into
`Mono.Posix.dll` for use by end-user applications. To do so, it needs
to `<Import/>` the Xamarin.Android MSBuild targets:
<Import Project="$(OutputPath)\..\..\..\xbuild\Xamarin\Android\Xamarin.Android.CSharp.targets" />
In a clean build tree -- e.g. immediately after checkout --
*the above file does not exist*. `Xamarin.Android.CSharp.targets` is
installed into the above directory by
`src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.csproj`
(via `%(None.CopyToOutputDirectory)` set to `PreserveNewest`), which
means that `Xamarin.Android.CSharp.targets` won't be available for
processing by `Mono.Posix.csproj` until *after*
`Xamarin.Android.Build.Tasks.csproj` has been built.
Under `xbuild`, this Just Works™: `Mono.Posix.csproj` has a
`@(ProjectReference)` to `Xamarin.Android.Build.Tasks.csproj`, so
`xbuild` loads `Mono.Posix.csproj` into an XML parser, extracts the
`@(ProjectReference)` items, and continues on its merry way *without*
evaluating the `<Import/>`s within `Mono.Posix.csproj`.
Under `msbuild`, this fails horrifically:
`Xamarin.Android.CSharp.targets` isn't in the expected directory,
and `msbuild` reports an MSB4019 error. MSBuild attempts to continue
(why?!), but nothing can actually build sanely.
There are two plausible fixes for this scenario:
1. Add a layer of indirection!
2. Abuse `make prepare`.
For option (1), see e.g. (b1f13708)
`build-tools/mono-runtimes/mono-runtimes.mdproj` and
`build-tools/mono-runtimes/mono-runtimes.targets`, in which the
`Build` target is altered so that nothing is done if the outputs
already exist; otherwise the `<MSBuild/>` task is used to invoke the
`ForceBuild` target. A similar thing could plausibly be done for
`Mono.Posix.csproj`, by creating a "proxy" project which is used by
`@(ProjectReference)` for determining the dependency graph, and the
"proxy" project then delegates to the "real" project.
I don't personally like this idea, as I'm not sure what it looks like
from the IDE. There would now be two projects instead of one for
*each* MSB4019 error, and there are *10* MSB4019 errors (now).
Option (2) involves altering `make prepare` so that when `msbuild` is
used, we explicitly build a set of projects *before*
`Xamarin.Android.sln` is built. This allows us to manually intervene
and build projects in an order which will appease `msbuild`s "eager"
resolving and loading of all referenced files.
This also works, is much simpler, and means we *don't* need to
introduce 10 additional project files simply to appease MSBuild.
Perhaps not surprisingly, that conceptual change -- the introduction
of `make prepare-msbuild` -- is *tiny* in this patch. Then we have
other `xbuild`-vs-`msbuild`-isms.
Bump to Java.Interop/65a0157f, as that commit is needed to build
cleanly with `msbuild`.
`android-toolchain.targets` can't use `$(_Toolchain)` because then
`%(_NdkToolchain.Identity)` isn't properly batched into the `<Exec/>`.
The result is a build error when invoking
`make-standalone-toolchain.sh` when it's invoked an additional time,
but without a corresponding `@(_NdkToolchain)`, so the command line is
just completely bizarro and fails.
`Mono.Data.Sqlite.csproj` and `Mono.Posix.csproj` need to set
`$(NoStdLib)` to True so that MSBuild doesn't add the *system*
`mscorlib.dll` when building the assemblies. When `$(NoStdLib)` is
False, the `<Csc/>` task is executed referencing *two* `mscorlib.dll`
assemblies, and things go badly from there.
`System.Drawing.Primitives.csproj` *does* properly set `$(NoStdLib)`
to True, but then it *also* set it to False in the Debug and Release
sections (?!). Remove the extra -- and wrong! -- overrides.
`Xamarin.Android.Build.Tasks.targets` needs to provide
`$(CscToolPath)` and `$(CscToolExe)` to the `<Csc/>` task. Otherwise,
`msbuild` defaults to trying to invoke `csc.exe`, which doesn't exist
on mono 4.6, breaking the `_BuildMonoSymbolicate` target.
Finally, `System.Runtime`... We have a bit of a history of adding a
`@(Reference)` to `System.Runtime` (452d405e) and removing that same
reference (9a50c668, b89dc15d). The short version is that `xbuild`
errors if `System.Runtime` is referenced, while `msbuild` errors if
`System.Runtime` *isn't* referenced. #facepalm
"Fix" this by altering `$(MSBUILD_FLAGS)` so that when building with
`xbuild` the `$(_XABuildingWithXBuild)` property is True. We can then
make the `@(Reference)`s to `System.Runtime` conditional on our *not*
building with `xbuild`. (This might mean we don't build from the IDE
until it uses `msbuild`; I haven't tested this.)
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-msbuild/87/consoleText
`tests/CodeGen-Binding` is a full-stack integration jack for JNI
bindings, ensuring that `generator.exe` and company work as expected.
It is *somewhat* duplicative of the Java.Interop `generator` unit
tests, except these are actually executed, while the `generator` tests
are *not* executed.
`tests/CodeGen-MkBundle` is a test for the "Bundle assemblies into
native code" feature, but isn't part of the "proper" unit test
infrastructure, as it doesn't yet contain an `Instrumentation` type.
TODO: Add an `Instrumentation` type to `tests/CodeGen-MkBundle`.
Now that we can run NUnit tests on-device (48e3fc26), the next step is
to start running unit tests on Jenkins, which is best done through the
`make run-all-tests` target.
...or so I thought.
In actuality, that's not *quite* right, because `make run-nunit-tests`
will bail on the first failure, which is not at all desirable. We want
to run *all* the tests, not just some subset of tests that pass.
Fix the `RUN_NUNIT_TEST` define so that an "error exit code" is
"ignored." This allows all NUnit-based tests to actually execute.
Even better, it means that the `make run-nunit-tests` target won't
fail, which means `make run-all-tests` can actually progress to
running `make run-apk-tests`, which were being skipped because the
`Xamarin.Android.Build.Tests.dll` tests had some failures.
<heavy sigh>
That's only half the problem on Jenkins. The other half is that the
Jenkins **Publish xUnit test result report** step, using the
**NUnit-Version N/A (default)** pattern, was failing because the XSLT
used to process the NUnit XML output was emitting invalid XML:
<?xml version="1.0" encoding="UTF-8"?>
/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/packages/NUnit.ConsoleRunner.3.2.1/tools/nunit3-console.exe bin/TestDebug/Xamarin.Android.Build.Tests.dll --result=TestResult-Xamarin.Android.Build.Tests.xml -output=bin/TestDebug/TestOutput-Xamarin.Android.Build.Tests.txt
...
That's certainly not valid XML...
The problem here was that `nunit3-console.exe` was emitting
NUnit **3** XML output, while the Jenkins XSLT only supports
NUnit **2** output. The fix here is twofold:
1. Update `pakcages.config` to also install the `NUnit.Console`
and `NUnit.Extension.NUnitV2ResultWriter` packages.
(Only the `NUnit.Console` package should be required, as it
depends on the latter, but for some reason referencing *just*
`NUnit.Console` didn't cause `NUnit.Extension.NUnitV2ResultWriter`
to be installed on my local machine.)
2. Update the `nunit3-console.exe` invocation to specify the output
format, which is a `;format=nunit2` *suffix* on `--result`:
nunit3-console.exe "--result=TestResult.xml;format=nunit2" ...
(Using `;format=nunit2` *requires* the
`NUnit.Extension.NUnitV2ResultWriter` package.)
Next, when the `<CheckAdbTarget/>` ran the following command:
$ adb shell getprop ro.build.version.sdk
When stdout contained an informational or error message:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: device '(null)' not found
This was erroniously treated as "valid" output when
`CheckAdbTarget.SdkVersion` wasn't specified. Fix the
`<CheckAdbTarget/>` task so that informational and error messages are
ignored.
Finally, for currently unknown reasons, when the
`<RunInstrumentationTests/>` task is ran on Jenkins, the
`nunit2-results-path` may contain a `\r`, resulting in an error trying
to copy the file off the device:
Tool .../adb execution started with arguments: pull "/data/data/Mono.Android_Tests/files/.__override__/TestResults.xml^M" "../TestResult-Mono.Android_Tests.xml"
...
remote object '/data/data/Mono.Android_Tests/files/.__override__/TestResults.xml^M' does not exist
Fix this by using `string.Trim()` to remove whitespace characters from
`targetTestResultsPath`.
With all those changes in place, I *hope* Jenkins will be able to
(1) *run* all unit tests, and (2) *display* the results of those unit
tests in a nice, readable, graphical, form.
What do we want? Execution of unit tests!
When do we want it? Uh...4 months ago?
The `Xamarin.Android.NUnitLite` assembly allows writing NUnit-based
unit tests that execute on-device, and the `Mono.Android-Tests.csproj`
project contains a number of such unit tests.
The problem is that these unit tests aren't executed as part of the
Jenkins build process, so there's no way to know if a given commit
actually breaks anything.
In short, the existence of those unit tests is meaningless.
The task, then, is to fix the `make run-all-tests` target so that it
runs on-device unit tests...on an Android device.
Which raises all manner of problems. :-) (Hence 4+ months!)
For starters, our internal tooling is a horrible mish-mash of make(1),
ruby(1), bash(1), which creates an emulator, launches it, installs the
test .apk onto the emulator, and runs the tests. I don't want all of
that "cruft" in this repo, which means it needs to be rewritten in a
form more amenable to this repo: MSBuild tasks....and some make(1).
:-)
Add a new `build-tools/scripts/UnitTestApks.targets` file, which will
process an `@(UnitTestApk)` Item Group to permit deploying, running,
and undeploying test .apks from an attached Android device.
Add a slew of MSBuild tasks to support `@(UnitTestApk)`.
Update the default `$(AndroidSupportedTargetJitAbis)` value to be
`armeabi-v7a:x86`. The created Android emulator is x86.
Context: https://github.com/xamarin/xamarin-android/pull/269#issuecomment-254540565
Various features such as the Xamarin Studio Android Designer require a
`libmono-android.debug.dylib` file, built for the *host* OS, not for
an Android target device.
Add build system support to build `libmono-android.*` for the host OS,
including an MXE-cross-compiled Windows host version.
Turns out that [ -f '' ] is true, but [ -f "''" ] is, correctly,
false. This makes difference between detecting presence of absent
mono64 binary (which returns '') and properly detecting its
absence.
Context: fbfd676c10
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
Jonathan Pryor
Marek Habersack
Jonathan Peppers
Alexander Köplinger
Dean Ellis
Radek Doulik
Radek Doulik
Atsushi Eno
Harry
Tim Wanders