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`
- Needed to `nuget restore Xamarin.Android-Tests.sln`
- Added `$(XAIntegratedTests)` property which defaults to True.
Windows will need to set this property in order to build
`Xamarin.Android-Tests.sln`
- Some project references in `Mono.Android-Tests.csproj` should
be conditional against `$(XAIntegratedTests)`==True
- Usage of `zip -r` is replaced with `jar cf` using `$(JarPath)`
(Windows doesn't have `zip`)
- `Xamarin.Android.Build.Tasks.csproj` had a file-locking issue
similar to `create-vsix.csproj` (2bca09d1): the
`_GenerateXACommonProps` target needs to depend on `ResolveReferences`
Other changes:
- Update README
- Update .gitignore for `.gradle/` and `*.user` files
* Bump LibZipSharp for Windows fixes
Problems fixed on Windows:
- Many `RequiredPrograms` are n/a on Windows
- Setup `AndroidSdkItem` for Windows downloads
- `AcceptAndroidSdkLicenses` should run `.bat` file on Windows
- `UnzipDirectoryChildren` was running `/bin/mv` and hitting
`PathTooLongException` while using `ZipFile.ExtractToDirectory`
- references to `libzip.mdproj` are conditional on Windows, will be
getting `libzip` from NuGet in the future
UnzipDirectoryChildren:
- on Windows we are using `System.IO.Compression` to extract
directly into the destination and avoid `%TEMP%` to
workaround `MAX_PATH`
- Other platforms continue to use `unzip`, in order to preserve
file attributes
General changes:
- gitignore for VS 2017
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.
The commit implements building of LLVM and cross-compilers to support
Xamarin.Android/Mono AOT. LLVM and cross-compilers can be built for
both the host platform (Linux and OS/X at the moment) as well as
cross-compiled for 32-bit and 64-bit Windows platforms.
Windows builds are done with MXE toolchain on OS/X and with the packaged
mingw-w64 toolchain on Linux (tested on Ubuntu 16.04 ONLY).
Also introducing a new set of MSBuild properties that contain information
about the host system. Some of those properties (HostOS, HostCC, HostCXX
for instance) have been moved from Configuration.props to better support
auto-detection. A new script, build-tools/scripts/generate-os-info, is
invoked as part of `make prepare` to generate file that contains the
new properties. The generated file is required for the build to work and
is also host-specific (it mustn't be moved between different machines)
Cross compiler builds require access to a configured Mono build tree, in
order to generate C structure offsets header file that is used by the AOT
compilers to properly generate AOT-ed binaries. Therefore, even if a JIT
target is not enabled in the configuration, enabling a cross-compiler for
some target will configure Mono for that JIT target but it will NOT build
it, to save time. To facilitate this, the _MonoRuntimes items defined in
build-tools/mono-runtimes/mono-runtimes.projitems gain an additional metadata
item called `DoBuild` which will be set to `true` if the runtime actually needs
to be built, as opposed to just configured.
MXE builds are disabled on Linux as mingw-w64 works just fine.
A `make prepare` warning is issued for Linux hosts which have the binfmt_misc
module enabled and either Wine of Mono (cli) registered as PE32/PE32+ binary
interpreters. In such instance building of the Windows cross-compilers will
fail because Autotools determine whether software is being cross compiled by
building a test program and attempting to execute it. In normal circumstances
such an attempt will fail, but with Windows cross-compilation and either Wine
or Mono registered to handle the PE32 executables this attempt will succeed
thus causing the cross compilation detection to fail.
Currently to build cross compilers on Linux you need to generate the C structure
offsets header file on OS/X and copy the resulting headers to appropriate places
on Linux. The header files should be placed in
build-tools/mono-runtimes/obj/Debug/cross-*/
directories. The header files are:
{cross-arm,cross-arm-win}/aarch64-v8a-linux-android.h
{cross-arm64,cross-arm64-win}/armv5-none-linux-androideabi.h
{cross-x86,cross-x86-win}/i686-none-linux-android.h
{cross-x86_64,cross-x86_64-win}/x86_64-none-linux-android.h
Offsets header generation doesn't work on Linux atm because of missing support
for it in the Mono utility used to generate the offsets. Hopefully this limitation
will be removed in the near future and a start-to-end build of everything will be
possible on Linux.
It is now mandatory to run at least `make prepare-props` before Xamarin.Android
can be built. The target generates the OS-specific props file which is required
by the build. `make prepare` depends on the target.
This commit adds basic support for the MSBuild Unit Tests. The goal
of these tests is to ensure that the build of an android applicaition
works consistently on all the supported platforms.
The basic layout of a Unit test is as follows
[Test]
public void BuildReleaseApplication ()
{
var proj = new XamarinAndroidApplicationProject () {
IsRelease = true,
};
using (var b = CreateApkBuilder (Path.Combine ("temp", TestContext.CurrentContext.Test.Name))) {
Assert.IsTrue (b.Build (proj), "Build should have succeeded.");
}
}
It is a standard Unit test. First we create a XamarinAndroidApplicatonProject
and set its properties. You can use the proj to add new source files,
references, assets, resources and nuget packages. By default you will get
a standard "HelloWorld" android application.
Once you have the project you will need to create either a Apk or Dll builder
via the helper methods
CreateApkBuilder
CreateDllBuilder
CreateApkBuilder will create an apk and by default will execute the
`SignAndroidPackage` build target. the CreateDllBuilder will produce
a dll. The source files are created in a temp directory relative to
the build output of the unit tests. By default this is
src/Xamarin.Android.Build.Tasks/UnitTests/Xamarin.Android.Build.Tests/bin/$(Configuraiton)/temp
Once you have a builder you can then call Build passing in the project. There are
also methods available for Clean and Save. Running any of these will cause
the Unit test to shell out to xbuild/msbuild and attempt to build the project.
Test results are written to a build.log file.
If a unit test passes then the test directory is removed. If a test fails
the directory and the build.log will be left in place for investigation.
Added Xamarin.Android.Build.Tasks and its supporting Libraries.
Code has also been updated to make uses of the new libraries in
the Java.Interop repository
Note : Xamarin.Android.Build.Tasks has a compile time code
generation step which generates Profile.g.cs. This file contains
the list of SharedRuntimeAssemblies. If building manually you will
need to make sure that Xamarin.Android.Tools.BootstrapTasks is
built first.
This might be a suspect idea, but lets see if we can make this work.
[The Joel Test: 12 Steps to Better Code][0] outlines 12 steps
to better code. The first two steps are:
1. Do you use source control?
2. Can you make a build in one step?
github is being used for source control, so (1) is handled, but how
simple can we make (2)? How easy can we make it to build
Xamarin.Android upon a fresh checkout?
The ideal to strive for is simple:
Load Xamarin.Android.sln into your IDE and Build the project.
I *know* we're not going to be able to do this, if only because we're
going to be using git submodules, which will require a separate
`git submodule init` invocation [1].
Knowing we can't reach that level of simplicitly doesn't mean we
shouldn't *try* to reach it for all other parts of the build system.
Which brings us to the Android NDK and SDK. The Android NDK will be
required in order to build native code, such as libmonodroid.so, while
the Android SDK will be required in order to compile
Java Callable Wrappers (née Android Callable Wrappers [2]) and
eventual samples and unit tests.
There are three ways we can deal with the Android NDK and SDK:
1. Complicate the "build" process by requiring that developers go to
the Android SDK Download Page [3], download and install
"somewhere" the required bits, and then configure the
Xamarin.Android build to use these bits.
2. Complicate the "build" process by requiring that developers run
the Xamarin Unified Installer [4], let it install everything
required, then configure the Xamarin.Android build to use those
bits.
3. Painstakingly determine which files are actually required, then
automatically download and extract those files into a "well-known"
location known by the Xamarin.Android build process.
(1) and (2) can be infuriating. Let's give (3) a try. :-)
Add a Xamarin.Android.Tools.BootstrapTasks project which contains
MSBuild tasks to facilitate downloading the Android SDK and NDK files.
Add an android-toolchain project which uses
Xamarin.Android.Tools.BootstrapTasks to download a painstakingly
determined set of files and install them "somewhere".
Unfortunately [5] the "somewhere" to download and install these files
needs to be in a known absolute path, so I've arbitrary decided to
download the files into $(HOME)\android-archives and install them into
$(HOME)\android-toolchain. On windows, this is
%HOMEDRIVE%%HOMEPATH%\android-archives and
%HOMEDRIVE%%HOMEPATH%\android-toolchain.
These locations may be modified by creating a
Configuration.Override.props file; see README.md for details.
TL;DR: This setup is able to magically download the Android NDK and
SDK files and install them for later use in a reasonably overridable
location, all within MSBuild.
[0]: http://www.joelonsoftware.com/articles/fog0000000043.html
[1]: Though maybe there's some MSBuild-fu we can use to address that.
[2]: https://developer.xamarin.com/guides/android/advanced_topics/java_integration_overview/android_callable_wrappers/
[3]: http://developer.android.com/sdk/index.html
[4]: https://www.xamarin.com/download
[5]: Because I couldn't find a reliable way to use $(SolutionDir) when
only building a project, and relative paths would require an
in-tree installation location, which might not work.
Jonathan Peppers
Radek Doulik
Jonathan Pryor
Marek Habersack
Dean Ellis