xamarin
/
xamarin-android
зеркало из https://github.com/xamarin/xamarin-android.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-android/Makefile

182 строки
5.1 KiB
Makefile
Исходник Обычный вид История

Use simply expanded variables They are faster since they are evaluated only once, and in this case that's all we need.
2016-06-27 22:17:34 +03:00
OS := $(shell uname)
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
OS_ARCH := $(shell uname -m)
Build stuff (#17) * Add the V make parameter to enable verbose logging Setting V to anything than 0 (zero) enables verbose logging for {ms,x}build as well as exports MONO_OPTIONS=--debug to enable stack traces should an exception be thrown when running mono. To add/override MONO_OPTIONS simply set it on the command line when invoking make, for instance: make V=1 MONO_OPTIONS="--trace" * File.Move doesn't overwrite targets File.Move will throw an exception whenever the target file exists. Assuming that the task should overwrite the existing target files for smooth operation, this change checks whether the target file exists and, if so, deletes it prior to calling File.Move
2016-05-04 15:03:01 +03:00
V ?= 0
[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-19 03:33:04 +03:00
CONFIGURATION = Debug
Fix runtime name detection 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.
2016-09-14 20:50:54 +03:00
RUNTIME := $(shell if [ -f "`which mono64`" ] ; then echo mono64 ; else echo mono; fi) --debug=casts
[Xamarin.Android-Tests] Split out "full" apps (#146) We're trying to get [`make jenkins`][0] working on Jenkins, and [it's failing][1], as one might expect when a particular repo and associated build system has never been run on Jenkins before: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? This error occurs while building `src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced... because it isn't *found*: Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved This returns us to a long-standing issue which I thought was mentioned in a commit somewhere, but I can't find at present: MSBuild doesn't support updating the assembly resolution directories *while MSBuild is running*. For example, we build `Xamarin.Android.NUniteLite.dll` into `bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`, but "normal Xamarin.Android referencing projects" don't use a `@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but instead a `@(Reference)` to the assembly: <!-- src/Mono.Android/Test/Mono.Android-Tests.csproj --> <Reference Include="Xamarin.Android.NUnitLite" /> The *requirement* for a "proper" Xamarin.Android SDK install is that `Xamarin.Android.NUnitLite.dll` can be found through a normal `@(Reference)`. In order to satisfy this requirement, we need to tell MSBuild where to find it, which can be with `xbuild` via the `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` *environment variables*. *Environment variables*. MSBuild doesn't provide a way to update environment variables, short of writing a new Task which calls `Environment.SetEnvironmentVariable()`, and while [this works][2], it doesn't *actually* work [^3]. The short of all this is that it isn't possible, *within a single `xbuild` invocation*, to both build the Xamarin.Android SDK "environment" *and use that environment* as intended for "normal" apps. The fix, as is often the case, is to bend with the wind. Instead of requiring the impossible, move `src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new* `Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`. This allows building `Xamarin.Android.sln` without error in a pristine environment -- that is, one that doesn't already have a system-wide Xamarin.Android install -- and separately building the tests by using `tools/scripts/xabuild`, which *can* export environment variables to manipulate `xbuild` behavior so that things Just Work™. Building `Mono.Android-Tests.csproj` and similar projects (`HelloWorld.csproj`!) can be done by using the new `make all-tests` make target. [0]: https://github.com/xamarin/xamarin-android/commit/a16673d3eb2c4945c3a74f5f8154603d7658fc9a [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console [2]: https://github.com/xamarin/xamarin-android/pull/147 [^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4]. There's no way to clear/invalidate `target_framework_cache`. The idea of PR #147 was to "hack things up" so that `Xamarin.Android.NuniteLite.dll` would be properly resolved during the build of `Mono.Android-Tests.csproj` *when building everything*. The problem is *this can't work*, because `xbuild` has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is *before* `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't exist in the cache. The result: Task "ResolveAssemblyReference" .... TargetFrameworkDirectories: /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/ ... Primary Reference System.Xml Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False ... Primary Reference Xamarin.Android.NUnitLite Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved For searchpath {TargetFrameworkDirectory} Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found. ... Consequently, the `mcs` invocation is missing a `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and compilation fails: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? ...plus 29 others... [4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 23:46:13 +03:00
SOLUTION = Xamarin.Android.sln
[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 21:54:03 +03:00
NUNIT_TESTS = \
bin/Test$(CONFIGURATION)/Xamarin.Android.Build.Tests.dll
NUNIT_CONSOLE = packages/NUnit.ConsoleRunner.3.2.1/tools/nunit3-console.exe
[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-19 03:33:04 +03:00
Build stuff (#17) * Add the V make parameter to enable verbose logging Setting V to anything than 0 (zero) enables verbose logging for {ms,x}build as well as exports MONO_OPTIONS=--debug to enable stack traces should an exception be thrown when running mono. To add/override MONO_OPTIONS simply set it on the command line when invoking make, for instance: make V=1 MONO_OPTIONS="--trace" * File.Move doesn't overwrite targets File.Move will throw an exception whenever the target file exists. Assuming that the task should overwrite the existing target files for smooth operation, this change checks whether the target file exists and, if so, deletes it prior to calling File.Move
2016-05-04 15:03:01 +03:00
ifneq ($(V),0)
MONO_OPTIONS += --debug
endif
ifneq ($(MONO_OPTIONS),)
export MONO_OPTIONS
endif
[build] Support building *from clean* with `msbuild` (#355) Context: https://github.com/xamarin/xamarin-android/commit/b1f1370896047966319655ea2b19a6a243719742 Context: https://github.com/xamarin/xamarin-android/commit/452d405e32e0b92dc1958f8ee3b101aae35ec859 Context: https://github.com/xamarin/xamarin-android/commit/9a50c668a4466915f07efd2fd0794b39ed84ba8c Context: https://github.com/xamarin/xamarin-android/commit/b89dc15d9bfeb2e6e03efbeb8e50895c372dbc5b 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
2017-01-10 19:16:40 +03:00
include build-tools/scripts/msbuild.mk
[Xamarin.Android-Tests] Split out "full" apps (#146) We're trying to get [`make jenkins`][0] working on Jenkins, and [it's failing][1], as one might expect when a particular repo and associated build system has never been run on Jenkins before: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? This error occurs while building `src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced... because it isn't *found*: Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved This returns us to a long-standing issue which I thought was mentioned in a commit somewhere, but I can't find at present: MSBuild doesn't support updating the assembly resolution directories *while MSBuild is running*. For example, we build `Xamarin.Android.NUniteLite.dll` into `bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`, but "normal Xamarin.Android referencing projects" don't use a `@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but instead a `@(Reference)` to the assembly: <!-- src/Mono.Android/Test/Mono.Android-Tests.csproj --> <Reference Include="Xamarin.Android.NUnitLite" /> The *requirement* for a "proper" Xamarin.Android SDK install is that `Xamarin.Android.NUnitLite.dll` can be found through a normal `@(Reference)`. In order to satisfy this requirement, we need to tell MSBuild where to find it, which can be with `xbuild` via the `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` *environment variables*. *Environment variables*. MSBuild doesn't provide a way to update environment variables, short of writing a new Task which calls `Environment.SetEnvironmentVariable()`, and while [this works][2], it doesn't *actually* work [^3]. The short of all this is that it isn't possible, *within a single `xbuild` invocation*, to both build the Xamarin.Android SDK "environment" *and use that environment* as intended for "normal" apps. The fix, as is often the case, is to bend with the wind. Instead of requiring the impossible, move `src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new* `Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`. This allows building `Xamarin.Android.sln` without error in a pristine environment -- that is, one that doesn't already have a system-wide Xamarin.Android install -- and separately building the tests by using `tools/scripts/xabuild`, which *can* export environment variables to manipulate `xbuild` behavior so that things Just Work™. Building `Mono.Android-Tests.csproj` and similar projects (`HelloWorld.csproj`!) can be done by using the new `make all-tests` make target. [0]: https://github.com/xamarin/xamarin-android/commit/a16673d3eb2c4945c3a74f5f8154603d7658fc9a [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console [2]: https://github.com/xamarin/xamarin-android/pull/147 [^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4]. There's no way to clear/invalidate `target_framework_cache`. The idea of PR #147 was to "hack things up" so that `Xamarin.Android.NuniteLite.dll` would be properly resolved during the build of `Mono.Android-Tests.csproj` *when building everything*. The problem is *this can't work*, because `xbuild` has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is *before* `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't exist in the cache. The result: Task "ResolveAssemblyReference" .... TargetFrameworkDirectories: /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/ ... Primary Reference System.Xml Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False ... Primary Reference Xamarin.Android.NUnitLite Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved For searchpath {TargetFrameworkDirectory} Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found. ... Consequently, the `mcs` invocation is missing a `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and compilation fails: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? ...plus 29 others... [4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 23:46:13 +03:00
all::
$(MSBUILD) $(MSBUILD_FLAGS) $(SOLUTION)
all-tests::
[tests] Run .apk unit tests and collect TestResults.xml (#305) 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.
2016-11-21 23:44:37 +03:00
MSBUILD="$(MSBUILD)" tools/scripts/xabuild $(MSBUILD_FLAGS) Xamarin.Android-Tests.sln
[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-19 03:33:04 +03:00
[build] Auto-Provision Dependencies (#447) 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.
2017-02-16 19:37:28 +03:00
prepare:: prepare-external prepare-props prepare-deps prepare-msbuild
[build] Ensure submodules init'd before using them (#131) `make jenkins` after a fresh checkout was failing: $ make jenkins cp Configuration.Java.Interop.Override.props external/Java.Interop/Configuration.Override.props ./build-tools/scripts/generate-os-info Configuration.OperatingSystem.props cp `xbuild /p:Configuration=Debug /nologo /v:minimal /t:GetMonoSourceFullPath build-tools/scripts/Paths.targets`/mcs/class/msfinal.pub . cp: /Volumes/Seagate4TB/work/xamarin-android/external/mono/mcs/class/msfinal.pub: No such file or directory make: *** [prepare-props] Error 1 The reason it failed is because `make prepare-props` ran *before* `git submodule update` ran, meaning the file `external/mono/mcs/class/msfinal.pub` didn't exist yet. Move the git submodule initialization logic into a new `make prepare-external` target, which is run before `make prepare-props`. This ensures that required files exist before they are used. Additionally, fix the `make prepare-external` logic so that if the `$(JavaInteropSourceDirectory)` MSBuild property is overridden, we run `nuget restore` from the appropriate directory.
2016-07-26 17:51:34 +03:00
[xa-prep-tasks] Use the Mono bundle (#162) Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c 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.
2016-08-16 23:02:48 +03:00
# $(call GetPath,path)
GetPath = $(shell $(MSBUILD) $(MSBUILD_FLAGS) /p:DoNotLoadOSProperties=True /nologo /v:minimal /t:Get$(1)FullPath build-tools/scripts/Paths.targets | tr -d '[[:space:]]' )
[build] Support building *from clean* with `msbuild` (#355) Context: https://github.com/xamarin/xamarin-android/commit/b1f1370896047966319655ea2b19a6a243719742 Context: https://github.com/xamarin/xamarin-android/commit/452d405e32e0b92dc1958f8ee3b101aae35ec859 Context: https://github.com/xamarin/xamarin-android/commit/9a50c668a4466915f07efd2fd0794b39ed84ba8c Context: https://github.com/xamarin/xamarin-android/commit/b89dc15d9bfeb2e6e03efbeb8e50895c372dbc5b 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
2017-01-10 19:16:40 +03:00
MSBUILD_PREPARE_PROJS = \
src/Xamarin.Android.Build.Tasks/Xamarin.Android.Build.Tasks.csproj
[build] Ensure submodules init'd before using them (#131) `make jenkins` after a fresh checkout was failing: $ make jenkins cp Configuration.Java.Interop.Override.props external/Java.Interop/Configuration.Override.props ./build-tools/scripts/generate-os-info Configuration.OperatingSystem.props cp `xbuild /p:Configuration=Debug /nologo /v:minimal /t:GetMonoSourceFullPath build-tools/scripts/Paths.targets`/mcs/class/msfinal.pub . cp: /Volumes/Seagate4TB/work/xamarin-android/external/mono/mcs/class/msfinal.pub: No such file or directory make: *** [prepare-props] Error 1 The reason it failed is because `make prepare-props` ran *before* `git submodule update` ran, meaning the file `external/mono/mcs/class/msfinal.pub` didn't exist yet. Move the git submodule initialization logic into a new `make prepare-external` target, which is run before `make prepare-props`. This ensures that required files exist before they are used. Additionally, fix the `make prepare-external` logic so that if the `$(JavaInteropSourceDirectory)` MSBuild property is overridden, we run `nuget restore` from the appropriate directory.
2016-07-26 17:51:34 +03:00
prepare-external:
[mono-runtimes] Build required mono runtimes. Add a new build-tools/mono-runtimes project to build the required Mono runtimes for Xamarin.Android app execution on Android devices. Xamarin.Android 6.0 ("cycle 6") includes Mono runtimes compiled for five architectures: * armeabi (armv5) * armeabi-v7a (armv7) * arm64-v8a (aarch64) * x86 * x86_64 An additional "host" architecture is also built to build the "monodroid" profile assemblies such as mscorlib.dll. In the interest of expediency and not requiring that *six* different runtimes be built -- which can greatly increase build times and storage requirements -- the initial xamarin-android open-source build will only build the armeabi-v7a (armv7) and "host" architectures. Additionally, the <UnzipDirectoryChildren/> task needed to be altered to use unzip(1) on OS X instead of using System.IO.Compression.ZipFile, because the ZipFile implementation included with Mono 4.4 doesn't respect file attributes such as the +x, causing all files to be extracted as 644 (rw-r--r--), resulting in an NDK toolchain which wouldn't work. To resolve this issue, execution on OS X and Linux now uses unzip(1). ~~ Adding new architectures ~~ To build Mono for a new architecture, edit build-tools/mono-runtimes/mono-runtimes.projitems and add a new @(_MonoRuntime) entry for the desired architecture. TODO: Figure out if there's a reasonable way to "opt-in" or "opt-out" of CPU architectures so that it isn't an "all or nothing" prospect.
2016-04-20 04:30:00 +03:00
git submodule update --init --recursive
[Xamarin.Android-Tests] Split out "full" apps (#146) We're trying to get [`make jenkins`][0] working on Jenkins, and [it's failing][1], as one might expect when a particular repo and associated build system has never been run on Jenkins before: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? This error occurs while building `src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced... because it isn't *found*: Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved This returns us to a long-standing issue which I thought was mentioned in a commit somewhere, but I can't find at present: MSBuild doesn't support updating the assembly resolution directories *while MSBuild is running*. For example, we build `Xamarin.Android.NUniteLite.dll` into `bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`, but "normal Xamarin.Android referencing projects" don't use a `@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but instead a `@(Reference)` to the assembly: <!-- src/Mono.Android/Test/Mono.Android-Tests.csproj --> <Reference Include="Xamarin.Android.NUnitLite" /> The *requirement* for a "proper" Xamarin.Android SDK install is that `Xamarin.Android.NUnitLite.dll` can be found through a normal `@(Reference)`. In order to satisfy this requirement, we need to tell MSBuild where to find it, which can be with `xbuild` via the `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` *environment variables*. *Environment variables*. MSBuild doesn't provide a way to update environment variables, short of writing a new Task which calls `Environment.SetEnvironmentVariable()`, and while [this works][2], it doesn't *actually* work [^3]. The short of all this is that it isn't possible, *within a single `xbuild` invocation*, to both build the Xamarin.Android SDK "environment" *and use that environment* as intended for "normal" apps. The fix, as is often the case, is to bend with the wind. Instead of requiring the impossible, move `src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new* `Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`. This allows building `Xamarin.Android.sln` without error in a pristine environment -- that is, one that doesn't already have a system-wide Xamarin.Android install -- and separately building the tests by using `tools/scripts/xabuild`, which *can* export environment variables to manipulate `xbuild` behavior so that things Just Work™. Building `Mono.Android-Tests.csproj` and similar projects (`HelloWorld.csproj`!) can be done by using the new `make all-tests` make target. [0]: https://github.com/xamarin/xamarin-android/commit/a16673d3eb2c4945c3a74f5f8154603d7658fc9a [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console [2]: https://github.com/xamarin/xamarin-android/pull/147 [^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4]. There's no way to clear/invalidate `target_framework_cache`. The idea of PR #147 was to "hack things up" so that `Xamarin.Android.NuniteLite.dll` would be properly resolved during the build of `Mono.Android-Tests.csproj` *when building everything*. The problem is *this can't work*, because `xbuild` has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is *before* `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't exist in the cache. The result: Task "ResolveAssemblyReference" .... TargetFrameworkDirectories: /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/ ... Primary Reference System.Xml Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False ... Primary Reference Xamarin.Android.NUnitLite Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved For searchpath {TargetFrameworkDirectory} Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found. ... Consequently, the `mcs` invocation is missing a `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and compilation fails: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? ...plus 29 others... [4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 23:46:13 +03:00
nuget restore $(SOLUTION)
nuget restore Xamarin.Android-Tests.sln
Bump to Java.Interop/f44a11f6 and use its Cecil library (#303) Updated all the projects to use the `Xamarin.Android.Cecil` library instead of `Mono.Cecil` nuget package.
2016-11-18 18:04:49 +03:00
(cd $(call GetPath,JavaInterop) && make prepare)
[monodroid] Build the host libmono-android* files. (#276) 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.
2016-10-24 18:05:01 +03:00
(cd $(call GetPath,JavaInterop) && make bin/BuildDebug/JdkInfo.props)
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
prepare-props:
[Xamarin.Android.Build.Tasks] Ensure `class-parse` is built first (#66) Proper execution of Xamarin.Android.Build.Tasks requires that `$prefix/lib/mandroid/class-parse.exe` exist. Unfortunately, nothing *created* that file, which means a default build didn't work. :-( Bump to Java.Interop/b6431ac8, which adds support for `Java.Interop/Configuration.Override.props`, update the `make prepare` target to create `external/Java.Interop/Configuration.Override.props`, and add Java.Interop's `class-parse` and `logcat-parse` to `Xamarin.Android.sln`. This causes `class-parse` to (1) be built, and (2) place its output into `bin/$(Configuration)/lib/mandroid`, as required by `Xamarin.Android.Build.Tasks.dll`.
2016-06-09 13:55:44 +03:00
cp Configuration.Java.Interop.Override.props external/Java.Interop/Configuration.Override.props
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
./build-tools/scripts/generate-os-info Configuration.OperatingSystem.props
[Xamarin.Android-Tests] Split out "full" apps (#146) We're trying to get [`make jenkins`][0] working on Jenkins, and [it's failing][1], as one might expect when a particular repo and associated build system has never been run on Jenkins before: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? This error occurs while building `src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced... because it isn't *found*: Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved This returns us to a long-standing issue which I thought was mentioned in a commit somewhere, but I can't find at present: MSBuild doesn't support updating the assembly resolution directories *while MSBuild is running*. For example, we build `Xamarin.Android.NUniteLite.dll` into `bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`, but "normal Xamarin.Android referencing projects" don't use a `@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but instead a `@(Reference)` to the assembly: <!-- src/Mono.Android/Test/Mono.Android-Tests.csproj --> <Reference Include="Xamarin.Android.NUnitLite" /> The *requirement* for a "proper" Xamarin.Android SDK install is that `Xamarin.Android.NUnitLite.dll` can be found through a normal `@(Reference)`. In order to satisfy this requirement, we need to tell MSBuild where to find it, which can be with `xbuild` via the `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` *environment variables*. *Environment variables*. MSBuild doesn't provide a way to update environment variables, short of writing a new Task which calls `Environment.SetEnvironmentVariable()`, and while [this works][2], it doesn't *actually* work [^3]. The short of all this is that it isn't possible, *within a single `xbuild` invocation*, to both build the Xamarin.Android SDK "environment" *and use that environment* as intended for "normal" apps. The fix, as is often the case, is to bend with the wind. Instead of requiring the impossible, move `src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new* `Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`. This allows building `Xamarin.Android.sln` without error in a pristine environment -- that is, one that doesn't already have a system-wide Xamarin.Android install -- and separately building the tests by using `tools/scripts/xabuild`, which *can* export environment variables to manipulate `xbuild` behavior so that things Just Work™. Building `Mono.Android-Tests.csproj` and similar projects (`HelloWorld.csproj`!) can be done by using the new `make all-tests` make target. [0]: https://github.com/xamarin/xamarin-android/commit/a16673d3eb2c4945c3a74f5f8154603d7658fc9a [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console [2]: https://github.com/xamarin/xamarin-android/pull/147 [^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4]. There's no way to clear/invalidate `target_framework_cache`. The idea of PR #147 was to "hack things up" so that `Xamarin.Android.NuniteLite.dll` would be properly resolved during the build of `Mono.Android-Tests.csproj` *when building everything*. The problem is *this can't work*, because `xbuild` has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is *before* `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't exist in the cache. The result: Task "ResolveAssemblyReference" .... TargetFrameworkDirectories: /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/ ... Primary Reference System.Xml Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False ... Primary Reference Xamarin.Android.NUnitLite Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved For searchpath {TargetFrameworkDirectory} Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found. ... Consequently, the `mcs` invocation is missing a `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and compilation fails: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? ...plus 29 others... [4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 23:46:13 +03:00
cp `$(MSBUILD) $(MSBUILD_FLAGS) /nologo /v:minimal /t:GetMonoSourceFullPath build-tools/scripts/Paths.targets`/mcs/class/msfinal.pub .
[mono-runtimes] Build required mono runtimes. Add a new build-tools/mono-runtimes project to build the required Mono runtimes for Xamarin.Android app execution on Android devices. Xamarin.Android 6.0 ("cycle 6") includes Mono runtimes compiled for five architectures: * armeabi (armv5) * armeabi-v7a (armv7) * arm64-v8a (aarch64) * x86 * x86_64 An additional "host" architecture is also built to build the "monodroid" profile assemblies such as mscorlib.dll. In the interest of expediency and not requiring that *six* different runtimes be built -- which can greatly increase build times and storage requirements -- the initial xamarin-android open-source build will only build the armeabi-v7a (armv7) and "host" architectures. Additionally, the <UnzipDirectoryChildren/> task needed to be altered to use unzip(1) on OS X instead of using System.IO.Compression.ZipFile, because the ZipFile implementation included with Mono 4.4 doesn't respect file attributes such as the +x, causing all files to be extracted as 644 (rw-r--r--), resulting in an NDK toolchain which wouldn't work. To resolve this issue, execution on OS X and Linux now uses unzip(1). ~~ Adding new architectures ~~ To build Mono for a new architecture, edit build-tools/mono-runtimes/mono-runtimes.projitems and add a new @(_MonoRuntime) entry for the desired architecture. TODO: Figure out if there's a reasonable way to "opt-in" or "opt-out" of CPU architectures so that it isn't an "all or nothing" prospect.
2016-04-20 04:30:00 +03:00
[build] Auto-Provision Dependencies (#447) 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.
2017-02-16 19:37:28 +03:00
prepare-deps:
$(MSBUILD) $(MSBUILD_FLAGS) build-tools/dependencies/dependencies.mdproj
[build] Support building *from clean* with `msbuild` (#355) Context: https://github.com/xamarin/xamarin-android/commit/b1f1370896047966319655ea2b19a6a243719742 Context: https://github.com/xamarin/xamarin-android/commit/452d405e32e0b92dc1958f8ee3b101aae35ec859 Context: https://github.com/xamarin/xamarin-android/commit/9a50c668a4466915f07efd2fd0794b39ed84ba8c Context: https://github.com/xamarin/xamarin-android/commit/b89dc15d9bfeb2e6e03efbeb8e50895c372dbc5b 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
2017-01-10 19:16:40 +03:00
prepare-msbuild:
ifeq ($(MSBUILD),msbuild)
for proj in $(MSBUILD_PREPARE_PROJS); do \
$(MSBUILD) $(MSBUILD_FLAGS) "$$proj"; \
done
endif # msbuild
[build] Add `make jenkins` target. (#116) The `make jenkins` [^0] target is for use by Continuous Integration machines, to build *everything* [^1]. This is expected to take an eternity. Think *hours*. $ time make jenkins ... real 130m11.608s user 97m22.220s sys 18m20.522s Of particular note is that the above "everything" includes *Release configuration builds* of everything, which is something that didn't actually work before. (Oops.) Bump Java.Interop so that it supports building the Release configuration, update Xamarin.Android.sln so that all required projects are part of the Release configuration, and update Xamarin.Android.Build.Tasks.csproj so that `JCW_ONLY_TYPE_NAMES` isn't defined, as this was preventing compilation. Fix **strip**(1) use: `mono-runtimes.targets` was trying to use `strip -S` on macOS, but the value of `%(_MonoRuntime.Strip)` was quoted, and thus attempted to execute `"strip -S" ...`, which failed. Move the `-S` into a new `%(_MonoRuntime.StripFlags)` value. Fixup `mono-runtimes.targets` and related files so that `$(MonoSourceFullPath)` is used instead of a relative path. This helps alleviate the "mental math" of determining the relative path to the Mono checkout. Plus, the Mono checkout is supposed to be overridable, e.g. commit d205cab2, and using `$(MonoSourceFullPath)` supports that. Download and install `android.jar` for all supported API levels. Fix the `Mono.Android.csproj` build so that `Mono.Android.dll` is stored in a per-API-level intermediate directory. Otherwise, if e.g. API-10 is built after API-23, the API-23 version will be installed, but the JCW build will fail. Additionally, API-24 requires using `javac -source 1.8 -target 1.8`, not 1.6. Fix `Mono.Android/metadata` to use the correct `merge.SourceFile` filename of `Profiles/api-24.xml.in`. Without that fix, API-24 won't build because `NumericShaper.GetContextualShaper()` is emitted twice, and the C# compiler doesn't like that. Disable use of `-lz` when building for Windows. Windows doesn't contain a `Z.DLL` to link against. [^0]: https://en.wikipedia.org/wiki/Leeroy_Jenkins [^1]: https://www.youtube.com/watch?v=hooKVstzbz0
2016-07-18 15:42:39 +03:00
include build-tools/scripts/BuildEverything.mk
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
# Please keep the package names sorted
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
ifeq ($(OS),Linux)
[build] Make package installation on Linux optional (#152) Xamarin.Android needs a number of packages to be installed on Linux in order to build properly. The makefile provides support for that but it requires using `sudo` to invoke the package installer. That may not be desired on build bots and so this commit makes package installation optional. In order to avoid package installation invoke make like so: make NO_SUDO=true prepare In this mode the makefile will merely report the installation status of all the dependency packages instead of installing them.
2016-08-09 22:07:00 +03:00
NO_SUDO ?= false
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
UBUNTU_DEPS = \
autoconf \
autotools-dev \
automake \
clang \
curl \
g++-mingw-w64 \
gcc-mingw-w64 \
git \
libtool \
libzip4 \
linux-libc-dev \
make \
openjdk-8-jdk \
unzip \
vim-common
ifeq ($(OS_ARCH),x86_64)
UBUNTU_DEPS += \
lib32stdc++6 \
lib32z1 \
libx32tinfo-dev \
linux-libc-dev:i386 \
zlib1g-dev:i386
endif
Use simply expanded variables They are faster since they are evaluated only once, and in this case that's all we need.
2016-06-27 22:17:34 +03:00
LINUX_DISTRO := $(shell lsb_release -i -s || true)
LINUX_DISTRO_RELEASE := $(shell lsb_release -r -s || true)
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
BINFMT_MISC_TROUBLE := cli win
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
prepare:: linux-prepare-$(LINUX_DISTRO) linux-prepare-$(LINUX_DISTRO)-$(LINUX_DISTRO_RELEASE)
[mono-runtimes] Build AOT+LLVM cross-compilers (#125) 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.
2016-07-26 16:27:31 +03:00
@BINFMT_WARN=no ; \
for m in $(BINFMT_MISC_TROUBLE); do \
if [ -f /proc/sys/fs/binfmt_misc/$$m ]; then \
BINFMT_WARN=yes ; \
fi ; \
done ; \
if [ "x$$BINFMT_WARN" = "xyes" ]; then \
cat Documentation/binfmt_misc-warning-Linux.txt ; \
fi
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
[build] Make package installation on Linux optional (#152) Xamarin.Android needs a number of packages to be installed on Linux in order to build properly. The makefile provides support for that but it requires using `sudo` to invoke the package installer. That may not be desired on build bots and so this commit makes package installation optional. In order to avoid package installation invoke make like so: make NO_SUDO=true prepare In this mode the makefile will merely report the installation status of all the dependency packages instead of installing them.
2016-08-09 22:07:00 +03:00
ifeq ($(NO_SUDO),false)
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
linux-prepare-Ubuntu::
[build] Make package installation on Linux optional (#152) Xamarin.Android needs a number of packages to be installed on Linux in order to build properly. The makefile provides support for that but it requires using `sudo` to invoke the package installer. That may not be desired on build bots and so this commit makes package installation optional. In order to avoid package installation invoke make like so: make NO_SUDO=true prepare In this mode the makefile will merely report the installation status of all the dependency packages instead of installing them.
2016-08-09 22:07:00 +03:00
@echo
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
@echo Installing build depedencies for $(LINUX_DISTRO)
@echo Will use sudo, please provide your password as needed
[build] Make package installation on Linux optional (#152) Xamarin.Android needs a number of packages to be installed on Linux in order to build properly. The makefile provides support for that but it requires using `sudo` to invoke the package installer. That may not be desired on build bots and so this commit makes package installation optional. In order to avoid package installation invoke make like so: make NO_SUDO=true prepare In this mode the makefile will merely report the installation status of all the dependency packages instead of installing them.
2016-08-09 22:07:00 +03:00
@echo
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
sudo apt-get -f -u install $(UBUNTU_DEPS)
[build] Make package installation on Linux optional (#152) Xamarin.Android needs a number of packages to be installed on Linux in order to build properly. The makefile provides support for that but it requires using `sudo` to invoke the package installer. That may not be desired on build bots and so this commit makes package installation optional. In order to avoid package installation invoke make like so: make NO_SUDO=true prepare In this mode the makefile will merely report the installation status of all the dependency packages instead of installing them.
2016-08-09 22:07:00 +03:00
else
linux-prepare-Ubuntu::
@echo
@echo sudo is disabled, cannot install dependencies
@echo Listing status of all the dependencies
@PACKAGES_MISSING=no ; \
for p in $(UBUNTU_DEPS); do \
if dpkg -l $$p > /dev/null 2>&1 ; then \
echo "[INSTALLED] $$p" ; \
else \
echo "[ MISSING ] $$p" ; \
PACKAGES_MISSING=yes ; \
fi ; \
done ; \
echo ; \
if [ "x$$PACKAGES_MISSING" = "xyes" ]; then \
echo Some packages are missing, cannot continue ; \
echo ; \
false ; \
fi
endif
Automatically install build dependencies on Linux The only distribution we haved support for right now is Ubuntu but it's trivial to add support for your distro of choice. To do so, run on command line: lsb_release -i -s and take note of the printed string - this is your distribution name as known to LSB. If the installation commands work for all releases of your distribution, add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME:: and provide commands to install the dependencies using your package manager below that line. If, however, some releases of your distribution require different commands or a different set of packages to install, run on command line: lsb_release -r -s And take note of the printed distribution release string. Then add the following target to the Makefile: linux-prepare-YOUR_DISTRO_NAME-DISTRO_RELEASE:: And omit the first target above. That's it!
2016-06-27 19:54:20 +03:00
linux-prepare-$(LINUX_DISTRO)::
linux-prepare-$(LINUX_DISTRO)-$(LINUX_DISTRO_RELEASE)::
endif
[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 21:54:03 +03:00
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
run-all-tests: run-nunit-tests run-apk-tests
[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 21:54:03 +03:00
[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-19 03:33:04 +03:00
clean:
[Xamarin.Android-Tests] Split out "full" apps (#146) We're trying to get [`make jenkins`][0] working on Jenkins, and [it's failing][1], as one might expect when a particular repo and associated build system has never been run on Jenkins before: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? This error occurs while building `src/Mono.Android/Test/Mono.Android-Tests.csproj`, and happens because the `Xamarin.Android.NUnitLite.dll` assembly isn't referenced... because it isn't *found*: Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved This returns us to a long-standing issue which I thought was mentioned in a commit somewhere, but I can't find at present: MSBuild doesn't support updating the assembly resolution directories *while MSBuild is running*. For example, we build `Xamarin.Android.NUniteLite.dll` into `bin/$(Configuration/lib/xbuild-frameworks/MonoAndroid/v1.0`, but "normal Xamarin.Android referencing projects" don't use a `@(ProjectReference)` to `Xamarin.Android.NUnitLite.csproj`, but instead a `@(Reference)` to the assembly: <!-- src/Mono.Android/Test/Mono.Android-Tests.csproj --> <Reference Include="Xamarin.Android.NUnitLite" /> The *requirement* for a "proper" Xamarin.Android SDK install is that `Xamarin.Android.NUnitLite.dll` can be found through a normal `@(Reference)`. In order to satisfy this requirement, we need to tell MSBuild where to find it, which can be with `xbuild` via the `$MSBuildExtensionsPath` and `$XBUILD_FRAMEWORK_FOLDERS_PATH` *environment variables*. *Environment variables*. MSBuild doesn't provide a way to update environment variables, short of writing a new Task which calls `Environment.SetEnvironmentVariable()`, and while [this works][2], it doesn't *actually* work [^3]. The short of all this is that it isn't possible, *within a single `xbuild` invocation*, to both build the Xamarin.Android SDK "environment" *and use that environment* as intended for "normal" apps. The fix, as is often the case, is to bend with the wind. Instead of requiring the impossible, move `src/Mono.Android/Test/Mono.Android-Tests.csproj` into a *new* `Xamarin.Android-Tests.sln` solution, *out of* `Xamarin.Android.sln`. This allows building `Xamarin.Android.sln` without error in a pristine environment -- that is, one that doesn't already have a system-wide Xamarin.Android install -- and separately building the tests by using `tools/scripts/xabuild`, which *can* export environment variables to manipulate `xbuild` behavior so that things Just Work™. Building `Mono.Android-Tests.csproj` and similar projects (`HelloWorld.csproj`!) can be done by using the new `make all-tests` make target. [0]: https://github.com/xamarin/xamarin-android/commit/a16673d3eb2c4945c3a74f5f8154603d7658fc9a [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/20/console [2]: https://github.com/xamarin/xamarin-android/pull/147 [^3]: [PR #147][2] isn't viable because of [xbuild's `AsssemblyResolver`][4]. There's no way to clear/invalidate `target_framework_cache`. The idea of PR #147 was to "hack things up" so that `Xamarin.Android.NuniteLite.dll` would be properly resolved during the build of `Mono.Android-Tests.csproj` *when building everything*. The problem is *this can't work*, because `xbuild` has a "target framework cache," with no way to invalidate it, and the cache is populated the first time the target framework is used. Due to build ordering issues, this first use is *before* `Xamarin.Android.NunitLite.dll` was built, and thus it doesn't exist in the cache. The result: Task "ResolveAssemblyReference" .... TargetFrameworkDirectories: /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0 /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/ ... Primary Reference System.Xml Reference System.Xml resolved to /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/System.Xml.dll. CopyLocal = False ... Primary Reference Xamarin.Android.NUnitLite Microsoft.Common.targets: warning : Reference 'Xamarin.Android.NUnitLite' not resolved For searchpath {TargetFrameworkDirectory} Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v7.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0, assembly named 'Xamarin.Android.NUnitLite' not found. Considered target framework dir /Volumes/Seagate4TB/work/xamarin-android/bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0/Facades/, assembly named 'Xamarin.Android.NUnitLite' not found. ... Consequently, the `mcs` invocation is missing a `/reference:path/to/Xamarin.Android.NUniteLite.dll`, and compilation fails: Android.App/ApplicationTest.cs(9,7): error CS0246: The type or namespace name `NUnit' could not be found. Are you missing an assembly reference? ...plus 29 others... [4]: https://github.com/mono/mono/blob/dd8aadf/mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/AssemblyResolver.cs#L131
2016-08-08 23:46:13 +03:00
$(MSBUILD) $(MSBUILD_FLAGS) /t:Clean Xamarin.Android.sln
tools/scripts/xabuild $(MSBUILD_FLAGS) /t:Clean Xamarin.Android-Tests.sln
[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 21:54:03 +03:00
Add a thorough clean make target `make distclean` will not only run `make clean` but it will also run `git clean -xdff` for the main project as well as the submodules thus giving you a pristine tree. Note that it will remove *all* of the files not in the git index as well as all the build artifacts! Use with care!
2016-06-10 17:07:34 +03:00
distclean:
# It may fail if we're cleaning a half-built tree, no harm done if we ignore it
-$(MAKE) clean
git clean -xdff
git submodule foreach git clean -xdff
[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 21:54:03 +03:00
# $(call RUN_NUNIT_TEST,filename,log-lref?)
define RUN_NUNIT_TEST
MONO_TRACE_LISTENER=Console.Out \
$(RUNTIME) --runtime=v4.0.0 \
$(NUNIT_CONSOLE) $(NUNIT_EXTRA) $(1) \
$(if $(RUN),-run:$(RUN)) \
[tests] `make run-nunit-tests` needs to emit NUnit2 XML (#308) 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.
2016-11-22 20:38:00 +03:00
--result="TestResult-$(basename $(notdir $(1))).xml;format=nunit2" \
-output=bin/Test$(CONFIGURATION)/TestOutput-$(basename $(notdir $(1))).txt \
|| true ;
[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 21:54:03 +03:00
endef
run-nunit-tests: $(NUNIT_TESTS)
$(foreach t,$(NUNIT_TESTS), $(call RUN_NUNIT_TEST,$(t),1))
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
[tests] Run .apk unit tests and collect TestResults.xml (#305) 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.
2016-11-21 23:44:37 +03:00
# .apk files to test on-device need to:
# (1) Have their .csproj files listed here
# (2) Add a `@(UnitTestApk)` entry to `tests/RunApkTests.targets`
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
TEST_APK_PROJECTS = \
[tests] Import tests/locale from monodroid/2ed1f0f6 (#316) Context: https://bugzilla.xamarin.com/show_bug.cgi?id=4902 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=15214 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=24742 Add tests around use of satellite assemblies and unit tests (!).
2016-11-24 19:05:45 +03:00
src/Mono.Android/Test/Mono.Android-Tests.csproj \
[tests] Import tests/codegen from monodroid/5fc80f27 `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`.
2016-11-29 17:41:17 +03:00
tests/CodeGen-Binding/Xamarin.Android.JcwGen-Tests/Xamarin.Android.JcwGen-Tests.csproj \
[tests] Import tests/locale from monodroid/2ed1f0f6 (#316) Context: https://bugzilla.xamarin.com/show_bug.cgi?id=4902 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=15214 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=24742 Add tests around use of satellite assemblies and unit tests (!).
2016-11-24 19:05:45 +03:00
tests/locales/Xamarin.Android.Locale-Tests/Xamarin.Android.Locale-Tests.csproj
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
[tests] Run .apk unit tests and collect TestResults.xml (#305) 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.
2016-11-21 23:44:37 +03:00
# Syntax: $(call BUILD_TEST_APK,path/to/project.csproj)
define BUILD_TEST_APK
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
# Must use xabuild to ensure correct assemblies are resolved
[tests] Run .apk unit tests and collect TestResults.xml (#305) 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.
2016-11-21 23:44:37 +03:00
MSBUILD="$(MSBUILD)" tools/scripts/xabuild /t:SignAndroidPackage $(1)
endef # BUILD_TEST_APK
[Mono.Android-Test] Import Mono.Android tests from monodroid/9c5b3712 (#32) Import monodroid/tests/runtime from monodroid/9c5b3712. Add a toplevel `make run-apk-tests` target to "full stack" tests, in which a .apk is created, installed, and executed on an attached Android device. `make run-apk-tests` requires that `adb` be in $PATH, and uses GNU make(1) features, and... Additionally, tools/scripts/xabuild *must* be used to execute the `SignAndroidPackage` target, to ensure that the local/"in tree" assemblies are used. There is no "within xbuild" facility to alter where target framework assemblies are resolved from, i.e no MSBuild properties currently control the resolution order, only environment variables, and MSBuild can't *set* environment variables... The $(ADB_TARGET) variable can be used to control on which target Android device the tests will be installed and executed on: # Install & run tests on *only* connected USB device $ make run-apk-tests ADB_TARGET=-d # Install & run tests on *only* connected emulator $ make run-apk-tests ADB_TARGET=-e # Install & run tests on specified device, listed via `adb devices`. $ make run-apk-tests ADB_TARGET="-s 036533824381cfcb" Sorry potential/future Windows developers. *Running* tests will require manual testing or running on OS X or Linux for now... Note: These tests DO NOT PASS. In fact, they *crash*: $ make run-apk-tests ... Target RunTests: Executing: "$HOME/android-toolchain/sdk/platform-tools/adb" shell am instrument -w Mono.Android_Tests/xamarin.android.runtimetests.TestInstrumentation INSTRUMENTATION_RESULT: shortMsg=Process crashed. INSTRUMENTATION_CODE: 0 $ adb logcat ... E mono : Unhandled Exception: E mono : System.ObjectDisposedException: Cannot access a disposed object. E mono : Object name: 'System.Net.Sockets.Socket'. E mono : at System.Net.Sockets.Socket.ThrowIfDisposedAndClosed () <0xa93923f0 + 0x00054> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f9680 + 0x0001b> in <filename unknown>:0 E mono : at System.Net.EndPointListener.Accept (System.Net.Sockets.Socket socket, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8f95d0 + 0x0003f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.ProcessAccept (System.Net.Sockets.SocketAsyncEventArgs args) <0x9b8e0340 + 0x0007f> in <filename unknown>:0 E mono : at System.Net.EndPointListener.OnAccept (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e0310 + 0x00017> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) <0x9b8e02c8 + 0x0003b> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncEventArgs.Complete () <0x9b8e02a0 + 0x0001f> in <filename unknown>:0 E mono : at System.Net.Sockets.Socket.<AcceptAsyncCallback>m__0 (System.IAsyncResult ares) <0x9b8dfd40 + 0x002af> in <filename unknown>:0 E mono : at System.Net.Sockets.SocketAsyncResult+<Complete>c__AnonStorey0.<>m__0 (System.Object _) <0xa892f720 + 0x0002b> in <filename unknown>:0 E mono : at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () <0xa938f6b8 + 0x0002f> in <filename unknown>:0 E mono : at System.Threading.ThreadPoolWorkQueue.Dispatch () <0xa938e358 + 0x001bb> in <filename unknown>:0 E mono : at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xa938e1a8 + 0x00007> in <filename unknown>:0 Looks like a Socket and/or ThreadPool bug in mono.
2016-05-16 21:55:13 +03:00
run-apk-tests:
[tests] Run .apk unit tests and collect TestResults.xml (#305) 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.
2016-11-21 23:44:37 +03:00
$(foreach p, $(TEST_APK_PROJECTS), $(call BUILD_TEST_APK, $(p)))
$(MSBUILD) $(MSBUILD_FLAGS) tests/RunApkTests.targets