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

340 строки
19 KiB
Plaintext
Исходник Обычный вид История

[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
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
<_SourceTopDir>..\..</_SourceTopDir>
<_BclFrameworkDir>$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0</_BclFrameworkDir>
[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
</PropertyGroup>
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
<UsingTask AssemblyFile="$(_SourceTopDir)\bin\Build$(Configuration)\Xamarin.Android.Tools.BootstrapTasks.dll" TaskName="Xamarin.Android.Tools.BootstrapTasks.GetNugetPackageBasePath" />
<Import Project="$(_SourceTopDir)\Configuration.props" />
[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
<PropertyGroup>
<_MonoProfileDir>$(MonoSourceFullPath)\mcs\class\lib\monodroid</_MonoProfileDir>
</PropertyGroup>
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
<Import Project="mono-runtimes.props" />
<Import Project="mono-runtimes.projitems" />
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
<ItemGroup>
<_BclAssembly Include="I18N.CJK.dll"/>
<_BclAssembly Include="I18N.dll"/>
<_BclAssembly Include="I18N.MidEast.dll"/>
<_BclAssembly Include="I18N.Other.dll"/>
<_BclAssembly Include="I18N.Rare.dll"/>
<_BclAssembly Include="I18N.West.dll"/>
<_BclAssembly Include="Microsoft.CSharp.dll"/>
<_BclAssembly Include="Mono.Cairo.dll"/>
<_BclAssembly Include="Mono.CompilerServices.SymbolWriter.dll"/>
<_BclAssembly Include="Mono.CSharp.dll"/>
<_BclAssembly Include="Mono.Data.Tds.dll"/>
<_BclAssembly Include="Mono.Security.dll"/>
<_BclAssembly Include="Mono.Security.Providers.DotNet.dll"/>
<_BclAssembly Include="Mono.Security.Providers.NewSystemSource.dll"/>
<_BclAssembly Include="Mono.Security.Providers.NewTls.dll"/>
<_BclAssembly Include="mscorlib.dll"/>
<_BclAssembly Include="SMDiagnostics.dll"/>
<_BclAssembly Include="System.ComponentModel.Composition.dll"/>
<_BclAssembly Include="System.ComponentModel.DataAnnotations.dll"/>
<_BclAssembly Include="System.Core.dll"/>
<_BclAssembly Include="System.Data.dll"/>
<_BclAssembly Include="System.Data.Services.Client.dll"/>
<_BclAssembly Include="System.dll"/>
<_BclAssembly Include="System.IO.Compression.dll"/>
<_BclAssembly Include="System.IO.Compression.FileSystem.dll"/>
<_BclAssembly Include="System.Json.dll"/>
<_BclAssembly Include="System.Net.dll"/>
<_BclAssembly Include="System.Net.Http.dll"/>
<_BclAssembly Include="System.Net.Http.WebRequest.dll"/>
Add new assemblies to mono-runtimes.targets (#118) Those were added as part of the netstandard effort.
2016-07-15 15:49:18 +03:00
<_BclAssembly Include="System.Net.Http.WinHttpHandler.dll"/>
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
<_BclAssembly Include="System.Numerics.dll"/>
Add new assemblies to mono-runtimes.targets (#118) Those were added as part of the netstandard effort.
2016-07-15 15:49:18 +03:00
<_BclAssembly Include="System.Numerics.Vectors.dll"/>
<_BclAssembly Include="System.Reflection.Context.dll"/>
<_BclAssembly Include="System.Reflection.DispatchProxy.dll"/>
<_BclAssembly Include="System.Runtime.InteropServices.RuntimeInformation.dll"/>
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
<_BclAssembly Include="System.Runtime.Serialization.dll"/>
Add new assemblies to mono-runtimes.targets (#118) Those were added as part of the netstandard effort.
2016-07-15 15:49:18 +03:00
<_BclAssembly Include="System.Security.dll"/>
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
<_BclAssembly Include="System.ServiceModel.dll"/>
<_BclAssembly Include="System.ServiceModel.Internals.dll"/>
<_BclAssembly Include="System.ServiceModel.Web.dll"/>
<_BclAssembly Include="System.Transactions.dll"/>
<_BclAssembly Include="System.Web.Services.dll"/>
<_BclAssembly Include="System.Windows.dll"/>
<_BclAssembly Include="System.Xml.dll"/>
<_BclAssembly Include="System.Xml.Linq.dll"/>
<_BclAssembly Include="System.Xml.Serialization.dll"/>
Add new assemblies to mono-runtimes.targets (#118) Those were added as part of the netstandard effort.
2016-07-15 15:49:18 +03:00
<_BclAssembly Include="System.Xml.XPath.XmlDocument.dll"/>
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
</ItemGroup>
<ItemGroup>
<_BclProfileItems Include="@(_BclAssembly->'$(_MonoProfileDir)\%(Identity)')" />
</ItemGroup>
<ItemGroup>
<_BclInstalledItem Include="@(_BclAssembly->'$(OutputPath)lib\xbuild-frameworks\MonoAndroid\v1.0\%(Identity)')" />
</ItemGroup>
[mono-runtimes] Rebuild mono when mono changes. (#36) The `mono-runtimes` project isn't resilient to mono changes, in large part because of the `_Autogen` target: `_Autogen` only executes if `$(_MonoPath)\autogen.sh` is newer than `$(_MonoPath)\configure`, and if the `_Autogen` target *doesn't* run, *no other targets* are re-executed either. Meaning if mono is bumped, e.g. as in commit cebaba20, the "newly updated" mono isn't necessarily rebuilt, because as far as the `_Autogen` target is concerned, nothing has changed (unless there is a commit which just happened to touch `autogen.sh`...which is a fairly infrequent occurrence). Add a new `_SetAutogenShTimeToLastCommitTimestamp` target which *always* touch(1)es `autogen.sh` to contain the timestamp of the most recent commit. That way, if (when) mono is updated, the timestamp of `autogen.sh` will be updated to match, allowing mono to be properly rebuilt. If mono *isn't* updated, the timestamp will be set to what it previously was, and no rebuild will occur. Note: `git log --date=format-local:...` must be used so that the resulting timestamp is in the *local* timezone. Otherwise, it's possible that if the current commit was done "in the future" relative to the current local timezone, `autogen.sh` will *always* have a more recent timestamp...until "tomorrow", anyway, and nobody wants to wait for "tomorrow".
2016-05-12 03:08:11 +03:00
<Target Name="_SetAutogenShTimeToLastCommitTimestamp">
<Exec
Command="touch -m -t `git log -1 --format=%25cd --date=format-local:%25Y%25m%25d%25H%25M.%25S` autogen.sh"
[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
WorkingDirectory="$(MonoSourceFullPath)"
[mono-runtimes] Rebuild mono when mono changes. (#36) The `mono-runtimes` project isn't resilient to mono changes, in large part because of the `_Autogen` target: `_Autogen` only executes if `$(_MonoPath)\autogen.sh` is newer than `$(_MonoPath)\configure`, and if the `_Autogen` target *doesn't* run, *no other targets* are re-executed either. Meaning if mono is bumped, e.g. as in commit cebaba20, the "newly updated" mono isn't necessarily rebuilt, because as far as the `_Autogen` target is concerned, nothing has changed (unless there is a commit which just happened to touch `autogen.sh`...which is a fairly infrequent occurrence). Add a new `_SetAutogenShTimeToLastCommitTimestamp` target which *always* touch(1)es `autogen.sh` to contain the timestamp of the most recent commit. That way, if (when) mono is updated, the timestamp of `autogen.sh` will be updated to match, allowing mono to be properly rebuilt. If mono *isn't* updated, the timestamp will be set to what it previously was, and no rebuild will occur. Note: `git log --date=format-local:...` must be used so that the resulting timestamp is in the *local* timezone. Otherwise, it's possible that if the current commit was done "in the future" relative to the current local timezone, `autogen.sh` will *always* have a more recent timestamp...until "tomorrow", anyway, and nobody wants to wait for "tomorrow".
2016-05-12 03:08:11 +03:00
/>
</Target>
[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
<Target Name="_PrepareLlvmItems">
<ItemGroup>
<_LlvmSourceFile Include="$(LlvmSourceFullPath)\lib\**\*.cpp" />
<_LlvmHeaderFile Include="$(LlvmSourceFullPath)\lib\**\*.h" />
<_LlvmMakefileConfig Include="@(_LlvmRuntime->'$(_LlvmOutputDirTop)\%(BuildDir)\Makefile.config')" />
<_LlvmConfigureStamp Include="@(_LlvmRuntime->'$(_LlvmOutputDirTop)\%(BuildDir)\.stamp-configure')" />
</ItemGroup>
<ItemGroup>
<_LlvmArchive Include="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)\Release\lib\*.a" />
<_LlvmSourceBinary Include="@(_LlvmRuntime->'$(_LlvmOutputDirTop)\%(BuildDir)\Release\bin\opt%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' " />
<_LlvmTargetBinary Include="@(_LlvmRuntime->'$(OutputPath)\bin\opt%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' "/>
<_LlvmSourceBinary Include="@(_LlvmRuntime->'$(_LlvmOutputDirTop)\%(BuildDir)\Release\bin\llc%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' " />
<_LlvmTargetBinary Include="@(_LlvmRuntime->'$(OutputPath)\bin\llc%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' " />
</ItemGroup>
</Target>
<Target Name="_ConfigureLlvm"
DependsOnTargets="_PrepareLlvmItems"
Inputs="$(LlvmSourceFullPath)\Makefile.config.in;$(LlvmSourceFullPath)\configure;@(_LlvmSourceFile);@(_LlvmHeaderFile)"
Outputs="@(_LlvmMakefileConfig);@(_LlvmConfigureStamp)"
Condition=" $(_LlvmNeeded) != '' ">
<MakeDir Directories="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)" />
<Exec
Command="%(_LlvmRuntime.ConfigureEnvironment) $(LlvmSourceFullPath)\configure %(_LlvmRuntime.ConfigureFlags)"
WorkingDirectory="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)"
/>
<Touch
Files="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)\Makefile.config"
/>
<Touch
Files="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)\.stamp-configure"
AlwaysCreate="true"
/>
</Target>
<Target Name="_BuildLlvm"
DependsOnTargets="_ConfigureLlvm"
Inputs="@(_LlvmConfigureStamp);@(_LlvmSourceFile);@(_LlvmHeaderFile)"
Outputs="@(_LlvmArchive);@(_LlvmSourceBinary)"
Condition=" '$(_LlvmNeeded)' != '' ">
<Exec
Command="%(_LlvmRuntime.BuildEnvironment) make $(MakeConcurrency) all install"
WorkingDirectory="$(_LlvmOutputDirTop)\%(_LlvmRuntime.BuildDir)"
/>
<Touch
Files="@(_LlvmArchive);@(_LlvmTargetBinary)"
/>
</Target>
<Target Name="_InstallLlvm"
DependsOnTargets="_BuildLlvm"
Inputs="@(_LlvmSourceBinary)"
Outputs="@(_LlvmTargetBinary)"
Condition=" '$(_LlvmNeeded)' != '' ">
<Copy
SourceFiles="@(_LlvmSourceBinary)"
DestinationFolder="$(OutputPath)\bin" />
<Touch
Files="@(_LlvmTargetBinary)" />
</Target>
[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
<Target Name="_Autogen"
[mono-runtimes] Rebuild mono when mono changes. (#36) The `mono-runtimes` project isn't resilient to mono changes, in large part because of the `_Autogen` target: `_Autogen` only executes if `$(_MonoPath)\autogen.sh` is newer than `$(_MonoPath)\configure`, and if the `_Autogen` target *doesn't* run, *no other targets* are re-executed either. Meaning if mono is bumped, e.g. as in commit cebaba20, the "newly updated" mono isn't necessarily rebuilt, because as far as the `_Autogen` target is concerned, nothing has changed (unless there is a commit which just happened to touch `autogen.sh`...which is a fairly infrequent occurrence). Add a new `_SetAutogenShTimeToLastCommitTimestamp` target which *always* touch(1)es `autogen.sh` to contain the timestamp of the most recent commit. That way, if (when) mono is updated, the timestamp of `autogen.sh` will be updated to match, allowing mono to be properly rebuilt. If mono *isn't* updated, the timestamp will be set to what it previously was, and no rebuild will occur. Note: `git log --date=format-local:...` must be used so that the resulting timestamp is in the *local* timezone. Otherwise, it's possible that if the current commit was done "in the future" relative to the current local timezone, `autogen.sh` will *always* have a more recent timestamp...until "tomorrow", anyway, and nobody wants to wait for "tomorrow".
2016-05-12 03:08:11 +03:00
DependsOnTargets="_SetAutogenShTimeToLastCommitTimestamp"
[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
Inputs="$(MonoSourceFullPath)\autogen.sh"
Outputs="$(MonoSourceFullPath)\configure">
[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
<Exec
Command="NOCONFIGURE=1 ./autogen.sh"
[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
WorkingDirectory="$(MonoSourceFullPath)"
[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
/>
</Target>
<Target Name="_ConfigureRuntimes"
[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
DependsOnTargets="_BuildLlvm"
[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
Inputs="$(MonoSourceFullPath)\configure"
[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
Outputs="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)\Makefile">
<MakeDir Directories="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)" />
[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
<Exec
[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
Command="$(MonoSourceFullPath)\configure LDFLAGS=&quot;%(_MonoRuntime.LdFlags)&quot; CFLAGS=&quot;%(_MonoRuntime.CFlags)&quot; CXXFLAGS=&quot;%(_MonoRuntime.CxxFlags)&quot; CC=&quot;%(_MonoRuntime.Cc)&quot; CXX=&quot;%(_MonoRuntime.Cxx)&quot; CPP=&quot;%(_MonoRuntime.Cpp)&quot; CXXCPP=&quot;%(_MonoRuntime.CxxCpp)&quot; LD=&quot;%(_MonoRuntime.Ld)&quot; AR=&quot;%(_MonoRuntime.Ar)&quot; AS=&quot;%(_MonoRuntime.As)&quot; RANLIB=&quot;%(_MonoRuntime.RanLib)&quot; STRIP=&quot;%(_MonoRuntime.Strip)&quot; DLLTOOL=&quot;%(_MonoRuntime.DllTool)&quot; OBJDUMP=&quot;%(_MonoRuntime.Objdump)&quot; --cache-file=..\%(_MonoRuntime.Identity).config.cache %(_MonoRuntime.ConfigureFlags)"
[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
WorkingDirectory="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)"
[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
/>
<Touch
[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
Files="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)\.stamp"
[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
AlwaysCreate="True"
/>
</Target>
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
<Target Name="_GetRuntimesOutputItems">
<ItemGroup>
[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
<_RuntimeLibraries Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(IntermediateOutputPath)%(Identity)\mono\mini\.libs\%(OutputRuntimeFilename).%(NativeLibraryExtension)')" />
<_InstallRuntimesOutputs Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputRuntimeFilename).%(NativeLibraryExtension)')" />
<_InstallUnstrippedRuntimeOutputs Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputRuntimeFilename).d.%(NativeLibraryExtension)')" />
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
<_RuntimeLibraries
[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
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' And '%(_MonoRuntime.OutputProfilerFilename)' != '' "
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
Include="@(_MonoRuntime->'$(IntermediateOutputPath)%(Identity)\mono\profiler\.libs\%(OutputProfilerFilename).%(NativeLibraryExtension)')"
/>
<_InstallRuntimesOutputs
[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
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' And '%(_MonoRuntime.OutputProfilerFilename)' != '' "
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputProfilerFilename).%(NativeLibraryExtension)')"
/>
[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
<_RuntimeLibraries Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(IntermediateOutputPath)%(Identity)\support\.libs\%(OutputMonoPosixHelperFilename).%(NativeLibraryExtension)')" />
<_InstallRuntimesOutputs Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputMonoPosixHelperFilename).%(NativeLibraryExtension)')" />
<_RuntimeBuildStamp Condition=" '%(_MonoRuntime.DoBuild)' == 'true' " Include="@(_MonoRuntime->'$(IntermediateOutputPath)%(Identity)\.stamp')" />
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
</ItemGroup>
</Target>
[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
<Target Name="_BuildRuntimes"
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
DependsOnTargets="_GetRuntimesOutputItems"
[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
Inputs="%(_RuntimeBuildStamp.Identity)"
Outputs="%(_RuntimeLibraries.Identity);@(_BclProfileItems)">
[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
<Exec
[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
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
Command="make $(MakeConcurrency) # %(_MonoRuntime.Identity)"
WorkingDirectory="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)"
[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
/>
[mono-runtimes] Fix _BuildRuntimes @Outputs checking. The _BuildRuntimes target was executing unnecessarily: Target _BuildRuntimes needs to be built as input file 'obj/Debug//armeabi-v7a/.stamp' is newer than output file 'obj/host/mono/profiler/.libs/libmono-profiler-log.dylib This would *always* be true, because the output files were never touched once they were built, so e.g. when copying a build tree from one machine to another (Dropbox!), the dependency check would be "wrong". Improve the _BuildRuntimes target to explicitly <Touch/> the output files so that -- short of timezone changes (!) -- the outputs will be forced to be newer than the inputs.
2016-04-23 14:54:47 +03:00
<Touch
[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
Files="%(_RuntimeLibraries.Identity);@(_BclProfileItems)"
[mono-runtimes] Fix _BuildRuntimes @Outputs checking. The _BuildRuntimes target was executing unnecessarily: Target _BuildRuntimes needs to be built as input file 'obj/Debug//armeabi-v7a/.stamp' is newer than output file 'obj/host/mono/profiler/.libs/libmono-profiler-log.dylib This would *always* be true, because the output files were never touched once they were built, so e.g. when copying a build tree from one machine to another (Dropbox!), the dependency check would be "wrong". Improve the _BuildRuntimes target to explicitly <Touch/> the output files so that -- short of timezone changes (!) -- the outputs will be forced to be newer than the inputs.
2016-04-23 14:54:47 +03:00
/>
[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
</Target>
<Target Name="_InstallRuntimes"
[mxe] Add Windows cross-compiler support. (#55) Certain Xamarin.Android features require that Mono be built for Windows, e.g. the [AOT compilers][aot] require a build of mono that executes on Windows to generate the AOT native libraries. Unfortunately, building Mono on Windows continues to be a massive PITA. (Autotools on Windows requires Cygwin/mingw, running shell scripts on Windows is painfully slow, it's all brittle, etc.) To work around this pain, we instead build the Mono/Windows binaries on OS X, via [MXE][mxe], which produces a gcc-based cross-compiler which generates Windows binaries and is executable from Unix. This in turn requires that we have MXE, so add a `_CreateMxeToolchains` target to `android-toolchain.targets` which will build MXE. The installation prefix for MXE can be overridden via the new `$(AndroidMxeInstallPrefix)` MSBuild property; it defaults to `$HOME/android-toolchain/mxe`. Rework the `$(AndroidSupportedAbis)` MSBuild property so that it must include the "host" ABI, and add support for a new `host-win64` value which will use MXE to generate 64-bit Windows binaries for libmonosgen-2.0.dll and libMonoPosixHelper.dll. We can't always process `host-$(HostOS)` because of an xbuild bug. The scenario is that if you want to just build `host-win64`, the obvious thing to do is: cd build-tools/mono-runtimes xbuild /p:AndroidSupportedAbis=host-win64 Alas, if `host-$(HostOS)` is always processed, this inexplicably causes `host-$(HostOS)` to be re-rebuilt, which (1) is a waste of time, and (2) fails -- inexplicably -- in the `_BuildRuntimes` target because make(1) thinks that the configure flags have somehow changed, which currently makes no sense at all. (When can we move to MSBuild?) Changing `$(AndroidSupportedAbis)` so that `host-$(HostOS)` is explicitly processed instead of implicitly processed allows working around the above xbuild bug, as `host-$(HostOS)` won't be implicitly processed on every build, but only when required. Additionally, we add a new <Which/> MSBuild task so that we can determine if a particular program is in `$PATH`. This is useful because listing requirements within README.md is a road to pain -- e.g. xxd(1) is required to build `src/monodroid` but if it's missing it'll still *build* but you'll instead get a *linker* failure because the `monodroid_config` and `monodroid_machine_config` symbols aren't present. Building MXE requires that even more programs be present within $PATH, so explicitly check for these so that *useful* error messages can be generated instead of obscure ones. Finally, a note about autotools and generating Windows native libraries: creation of `.dll` files *requires* that an appropriate objdump be present so it can determine if e.g. `libkernel32.a` is an import library or an archive. If `x86_64-w64-mingw32.static-objdump` isn't found -- e.g. because $PATH doesn't contain it -- then no `.dll` files will be created, and much head scratching will occur. To rectify this, override the OBJDUMP and DLLTOOL values when invoking `configure` so that that full paths are used and `$PATH` use is reduced. (Who wants `x86_64-w64-mingw32.static-objdump` in `$PATH`?) [aot]: https://developer.xamarin.com/releases/android/xamarin.android_5/xamarin.android_5.1/#AOT_Support [mxe]: http://mxe.cc/
2016-06-07 00:12:49 +03:00
DependsOnTargets="_GetRuntimesOutputItems"
[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
Inputs="%(_RuntimeLibraries.Identity)"
Outputs="%(_InstallRuntimesOutputs.Identity);%(_InstallUnstrippedRuntimeOutputs.Identity)">
<MakeDir
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
Directories="$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)"
/>
[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
<Copy
[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
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
[build-tools] Update library outputs to not include <abi> suffix (#47) The native libraries are output into an <abi> specific folder in lib/xbuild/Xamarin/Android/libs As a result we really do not need to have an <abi> suffix as part of the native library name. In additon the libmonosgen library was having -unstripped appended to the end of the library so it was libmonosgen-2.0.so-unstripped this looks a bit weird since it replaces the normal .so extension. This has been removed.
2016-05-27 15:51:12 +03:00
SourceFiles="@(_RuntimeLibraries)"
DestinationFiles="@(_InstallRuntimesOutputs)"
[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
/>
<Copy
[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
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
SourceFiles="$(IntermediateOutputPath)\%(_MonoRuntime.Identity)\mono\mini\.libs\%(_MonoRuntime.OutputRuntimeFilename).%(_MonoRuntime.NativeLibraryExtension)"
DestinationFiles="%(_InstallUnstrippedRuntimeOutputs.Identity)"
[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
/>
<Exec
[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
Condition=" '$(Configuration)' != 'Debug' And '%(_MonoRuntime.DoBuild)' == 'true' "
Command="&quot;%(_MonoRuntime.Strip)&quot; %(_MonoRuntime.StripFlags) &quot;$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)\%(_MonoRuntime.OutputRuntimeFilename).%(_MonoRuntime.NativeLibraryExtension)&quot;"
[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
/>
<Touch
[build-tools] Update library outputs to not include <abi> suffix (#47) The native libraries are output into an <abi> specific folder in lib/xbuild/Xamarin/Android/libs As a result we really do not need to have an <abi> suffix as part of the native library name. In additon the libmonosgen library was having -unstripped appended to the end of the library so it was libmonosgen-2.0.so-unstripped this looks a bit weird since it replaces the normal .so extension. This has been removed.
2016-05-27 15:51:12 +03:00
Files="@(_InstallRuntimesOutputs);@(_InstallUnstrippedRuntimeOutputs)"
[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
/>
</Target>
<Target Name="_InstallBcl"
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
Inputs="@(_BclProfileItems)"
Outputs="@(_BclInstalledItem);$(OutputPath)lib\xbuild-frameworks\MonoAndroid\v1.0\RedistList\FrameworkList.xml">
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
<MakeDir Directories="$(_BclFrameworkDir)" />
<MakeDir Directories="$(_BclFrameworkDir)\RedistList" />
<MakeDir Directories="$(_BclFrameworkDir)\Facades" />
[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
<ItemGroup>
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
<_PackageConfigFiles Include="$(_SourceTopDir)\src\Xamarin.Android.Build.Tasks\packages.config" />
</ItemGroup>
<GetNugetPackageBasePath PackageConfigFiles="@(_PackageConfigFiles)" PackageName="FSharp.Core">
<Output TaskParameter="BasePath" PropertyName="_FSharpCorePackagePath" />
</GetNugetPackageBasePath>
<ItemGroup>
<_FSharp Include="$(_SourceTopDir)\$(_FSharpCorePackagePath)\lib\portable-net45+monoandroid10+monotouch10+xamarinios10\FSharp.Core*" />
[mono-runtimes] Build mono if monodroid profile is missing (#39) If the mono build was aborted for whatever reason and the monodroid profile wasn't built completely (or at all) the current targets will not fail because they won't see any of the outputs missing and the _InstallBcl target will happily accept empty set for @(_Assemblies). We currently depend on a manually added full list of the monodroid profile assemblies (sans Mono.Data.Sqlite which will is built separately elsewhere and will not be built as part of the profile eventually), but we will implement a way to dynamically obtain the list of assemblies from mono.
2016-05-12 18:23:10 +03:00
<_Assemblies Include="$(_MonoProfileDir)\*.dll" />
<_Facades Include="$(_MonoProfileDir)\Facades\*.dll" />
[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
</ItemGroup>
<Copy
SourceFiles="@(_Assemblies)"
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
DestinationFolder="$(_BclFrameworkDir)"
[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
/>
<Copy
SourceFiles="@(_Facades)"
Copy FSharp support assemblies from nuget (#21) Instead of building F# from sources as we've been doing so far, we'll now use a nuget to get the binaries we require. This makes the build time much shorter.
2016-05-06 00:07:05 +03:00
DestinationFolder="$(_BclFrameworkDir)\Facades"
/>
<Copy
SourceFiles="@(_FSharp)"
DestinationFolder="$(_BclFrameworkDir)"
[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
/>
<Touch
[android-toolchains, mono-runtimes] Build armeabi, arm64-v8a, x86, x86_64 (#40) Commit 38dbfcaf mentions that commercial Xamarin.Android 6.0 provides Mono for five architectures, but "[i]n the interest of expediency" only adds support to build *one* architecture: armeabi-v7a (32-bit ARM v7). It's time to fix that: add build system support for armeabi, arm64-v8a, x86, and x86_64. *However*, it takes *time* to build all those ABIs: on a 2013 6-core Mac Pro, it takes ~29 minutes to build all five of those ABIs plus the "host" ABI (for BCL assemblies), which is presumably 29 minutes that very few people want to spend, and will be even longer in a variety of build environments (virtual machines, slower hardware, etc.). Which means we don't want to require that they all be built. To better support this, add a new `$(AndroidSupportedAbis)` MSBuild property which contains a comma-separated list of ABIs to support. This allows manually overriding the ABIs on the command-line: # build everything! $ xbuild /p:AndroidSupportedAbis=armeabi,armeabi-v7a,arm64-v8a,x86,x86_64 or setting a value within `Configuration.Override.props`: <PropertyGroup> <!-- only build x86 --> <AndroidSupportedAbis>x86,x86_64</AndroidSupportedAbis> </PropertyGroup> The *default* continues to be just armeabi-v7a.
2016-05-13 22:50:23 +03:00
Files="@(_BclInstalledItem)"
[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
/>
[xabuild] *Properly* package the .apk. Commit e20863ea adds an `xabuild` script, which allows us to build Android .apk application packages. And lo, it was good! *Unfortunately*, while a .apk was *generated*, the app on-device would immediately crash with a bizarre error. Further investigation pointed to the actual problem: While xamarin-android was generating the .apk, the framework assemblies that were bundled into the app were coming from the local system Xamarin.Android install. (Oops.) Two things are required in order to cause the correct assemblies to be bundled into the app.apk: 1. MSBuild/xbuild require that the bin/$(Configuration)/lib/xbuild-frameworks/MonoAndroid/v* directories contain a `RedistList/FrameworkList.xml` file, otherwise the directory isn't recognized as a valid location for MSBuild frameworks. Since these files were missing, the built assemblies weren't considered for use when compiling the app. Update the build system to generate these files. 2. Xamarin.Android.Common.targets was overriding the $(CscToolExe) and $(CscToolPath) MSBuild properties when running on OS X to refer to an `smcs` script, which (i) doesn't exist in the xamarin-android repo, so (ii) the system-installed smcs script was used instead. The smcs script is no longer necessary, and hasn't actually been required for *years* (behold! laziness!), so just remove these property overrides. With these two changes, `xabuild` is not only able to generate an Android .apk file, but the resulting .apk will actually run on-device! Woo-hoo!
2016-04-26 16:28:37 +03:00
<ItemGroup>
<FrameworkList Include="&lt;FileList Redist=&quot;MonoAndroid&quot; Name=&quot;Xamarin.Android Base Class Libraries&quot;&gt;" />
<FrameworkList Include="&lt;/FileList&gt;" />
</ItemGroup>
<WriteLinesToFile
File="$(OutputPath)lib\xbuild-frameworks\MonoAndroid\v1.0\RedistList\FrameworkList.xml"
Lines="@(FrameworkList)"
Overwrite="True"
/>
[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
</Target>
[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
<!-- The condition below is to work around a bug in xbuild which attempts to batch
even if there are no _MonoCrossRuntime items and the Copy task fails
-->
<Target Name="_ConfigureCrossRuntimes"
DependsOnTargets="_BuildLlvm"
Inputs="$(MonoSourceFullPath)\configure"
Outputs="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\Makefile;$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\.stamp"
Condition=" '@(_MonoCrossRuntime)' != '' ">
<MakeDir Directories="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)" />
<Exec
Command="%(_MonoCrossRuntime.ConfigureEnvironment) $(MonoSourceFullPath)\configure LDFLAGS=&quot;%(_MonoCrossRuntime.LdFlags)&quot; CFLAGS=&quot;%(_MonoCrossRuntime.CFlags)&quot; CXXFLAGS=&quot;%(_MonoCrossRuntime.CxxFlags)&quot; CC=&quot;%(_MonoCrossRuntime.Cc)&quot; CXX=&quot;%(_MonoCrossRuntime.Cxx)&quot; CPP=&quot;%(_MonoCrossRuntime.Cpp)&quot; CXXCPP=&quot;%(_MonoCrossRuntime.CxxCpp)&quot; LD=&quot;%(_MonoCrossRuntime.Ld)&quot; AR=&quot;%(_MonoCrossRuntime.Ar)&quot; AS=&quot;%(_MonoCrossRuntime.As)&quot; RANLIB=&quot;%(_MonoCrossRuntime.RanLib)&quot; STRIP=&quot;%(_MonoCrossRuntime.Strip)&quot; DLLTOOL=&quot;%(_MonoCrossRuntime.DllTool)&quot; OBJDUMP=&quot;%(_MonoCrossRuntime.Objdump)&quot; --cache-file=..\%(_MonoCrossRuntime.Identity).config.cache %(_MonoCrossRuntime.ConfigureFlags)"
WorkingDirectory="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)"
/>
<Touch
Files="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\.stamp"
AlwaysCreate="True"
/>
</Target>
<Target Name="_GenerateCrossOffsetHeaderFiles"
Inputs="$(MonoSourceFullPath)\configure"
Outputs="%(_MonoCrossRuntime.OffsetsHeader)"
Condition=" '$(HostOS)' != 'Linux' And '@(_MonoCrossRuntime)' != '' ">
<Exec
Command="make $(_AotOffsetsDumperName)"
WorkingDirectory="$(_AotOffsetsDumperSourceDir)"
/>
<Exec
Command="MONO_PATH=$(_AotOffsetsDumperSourceDir)\CppSharp $(ManagedRuntime) $(_AotOffsetsDumperSourceDir)\$(_AotOffsetsDumperName) --xamarin-android --android-ndk=&quot;$(AndroidNdkFullPath)&quot; --mono=&quot;$(MonoSourceFullPath)&quot; --monodroid=&quot;$(XamarinAndroidSourcePath)&quot; --abi=&quot;%(_MonoCrossRuntime.TargetAbi)&quot; --out=&quot;$(MSBuildThisFileDirectory)$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)&quot;"
WorkingDirectory="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)"
/>
<Touch
Files="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\%(_MonoCrossRuntime.OffsetsHeaderFile)"
/>
</Target>
<!-- The condition below is to work around a bug in xbuild which attempts to batch
even if there are no _MonoCrossRuntime items and the Copy task fails
-->
<Target Name="_BuildCrossRuntimes"
DependsOnTargets="_GenerateCrossOffsetHeaderFiles"
Inputs="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\.stamp"
Outputs="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
Condition=" '@(_MonoCrossRuntime)' != '' ">
<Message Text="Building %(_MonoCrossRuntime.Identity) in $(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)"/>
<Exec
Command="%(_MonoCrossRuntime.BuildEnvironment) make $(MakeConcurrency)"
WorkingDirectory="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)"
/>
<Touch
Files="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
/>
</Target>
<!-- The condition below is to work around a bug in xbuild which attempts to batch
even if there are no _MonoCrossRuntime items and the Copy task fails
-->
<Target Name="_InstallCrossRuntimes"
Inputs="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
Outputs="$(OutputPath)bin\%(_MonoCrossRuntime.CrossMonoName)"
Condition=" '@(_MonoCrossRuntime)' != '' ">
<MakeDir Directories="$(OutputPath)bin\" />
<Copy
SourceFiles="$(IntermediateOutputPath)%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
DestinationFiles="$(OutputPath)bin\%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
/>
<Touch
Files="$(OutputPath)bin\%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
/>
</Target>
[mono-runtimes] Use $(IntermediateOutputPath), not `obj`. One of the "cute" things in mono-runtimes.props is that $(_CommonCFlags) changes based on $(Configuration): for Debug builds, `-O0 -fno-omit-frame-pointer` is used (no optimizations and make stack traces easier for gdb), while for Release builds `-O2` is used. The natural result of this is that Debug and Release builds *are not the same*, and that's a *good* thing. ...except that previously, both Debug and Release builds used the same `obj\%(Identity)` directories, which meant there weren't separate Debug and Release outputs, there were instead "whatever was built first" outputs, which is *madness*. Fix mono-runtimes.targets so that $(IntermediateOutputPath) is used instead instead of `obj`. $(IntermediateOutputPath) should be `obj\$(Configuration)`, so Debug and Release build artifacts will be kept properly separate. Additionally, fix the `Clean` target, so that the $(IntermediateOutputPath) subdirectories are properly removed.
2016-04-22 21:30:39 +03:00
<Target Name="_CleanRuntimes"
AfterTargets="Clean">
[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
<RemoveDir Directories="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)');@(_MonoCrossRuntime->'$(IntermediateOutputPath)\%(Identity)');$(_LlvmBuildDir32);$(_LlvmBuildDir64);$(_LlvmBuildDirWin32);$(_LlvmBuildDirWin64)" />
<Delete Files="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity).config.cache');$(_CrossOutputPrefix)*.config.cache;$(_CrossOutputDirTop)\llvm*.config.cache" />
[mono-runtimes] Use $(IntermediateOutputPath), not `obj`. One of the "cute" things in mono-runtimes.props is that $(_CommonCFlags) changes based on $(Configuration): for Debug builds, `-O0 -fno-omit-frame-pointer` is used (no optimizations and make stack traces easier for gdb), while for Release builds `-O2` is used. The natural result of this is that Debug and Release builds *are not the same*, and that's a *good* thing. ...except that previously, both Debug and Release builds used the same `obj\%(Identity)` directories, which meant there weren't separate Debug and Release outputs, there were instead "whatever was built first" outputs, which is *madness*. Fix mono-runtimes.targets so that $(IntermediateOutputPath) is used instead instead of `obj`. $(IntermediateOutputPath) should be `obj\$(Configuration)`, so Debug and Release build artifacts will be kept properly separate. Additionally, fix the `Clean` target, so that the $(IntermediateOutputPath) subdirectories are properly removed.
2016-04-22 21:30:39 +03:00
</Target>
[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
</Project>