Граф коммитов

4 Коммитов

Автор SHA1 Сообщение Дата
Jonathan Pryor f48e55563b [System.Drawing.Primitives] Add System.Drawing.Primitives.dll Facade (#121)
Xamarin.Android needs to support [.NET Standard 1.6][0], which
mentions a [`System.Drawing.Primitives.dll` assembly][1] which has not
previously been supported or shipped.

`System.Drawing.Primitives.dll` contains `System.Drawing.Point` and
related typees, which Xamarin.Android places into `Mono.Android.dll`.

Add a new `System.Drawing.Primitives.dll` assembly to use as a
*facade assembly*, which contains [type forwarders][2] to
"redirect" the types from `System.Drawing.Primitives.dll` to the
corresponding types within `Mono.Android.dll`.

[0]: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries
[1]: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#list-of-net-corefx-apis-and-their-associated-net-platform-standard-version
[2]: https://msdn.microsoft.com/en-us/library/ms404275(v=vs.110).aspx
2016-07-15 16:42:03 -04:00
Dean Ellis 7634c6d4dc [Xamarin.Android.Build.Tasks] First Pass at adding Unit tests for the MSBuild Tasks (#26)
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.
2016-05-12 14:54:03 -04:00
Dean Ellis 59ec488b40 [Xamarin.Android.Build.Tasks] Import from monodroid/301e7238
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.
2016-04-25 17:06:36 +01:00
Jonathan Pryor 6fd330dfdd [android-toolchain] Permit zero-configuration builds.
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.
2016-04-18 21:08:18 -04:00