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">
|
[bundle] Create the bundle (#206)
Using the mono bundle (29568117, 57b18c27, ffe39776) didn't work as
well as intended, because *using* the mono bundle requires that the
bundle (1) *exist*, and (2) contain expected outputs.
Neither of which is true:
$ curl -o x.zip https://xamjenkinsartifact.blob.core.windows.net/xamarin-android/xamarin-android/bin/BuildDebug/bundle-v3-Debug-Darwin-libzip=1d8b1ac,llvm=8b1520c,mono=2c13a95.zip
$ file x.zip
x.zip: XML document text
$ cat x.zip
<?xml version="1.0" encoding="utf-8"?>
<Error>
<Code>BlobNotFound</Code>
<Message>The specified blob does not exist.
RequestId:f1722d1f-0001-0098-3fdd-fe4670000000
Time:2016-08-25T14:31:09.4102289Z
</Message>
</Error>
That is, the URL "exists", but it doesn't contain anything *useful*.
The bundle doesn't exist, in turn, because [*it isn't created*][0]:
Project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/build-tools/bundle/bundle.mdproj" (default target(s)):
...
Done building project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/build-tools/bundle/bundle.mdproj".
What's *missing* from the log file is any mention of the
`CreateBundle` target, which *creates the bundle*. Since the
`CreateBundle` target isn't invoked, *there is no bundle*, and thus
there's *nothing to upload*, and thus there's *nothing to download*,
either.
Why isn't the `CreateBundle` target executed? Because of property
group "overwrites". But first, a step back.
Remember 57b18c27?
> I *assume* that this is due to `<CallTarget/>` being "flakey" within
> xbuild (it passes the file containing the target to `<MSBuild/>`!),
> and *somehow* in that "flakiness" `$(OutputPath)` doesn't end with
> `\`, *which it should*, because `Microsoft.Common.targets` will
> automatically append `\` to `$(OutputPath)`.
Let's elaborate on the "flakiness" of xbuild: The `<CallTarget/>` task
doesn't *just* invoke the specified target. Rather, xbuild will
*reload the file containing the target*, "stand-alone", and execute
the target. It's "as if" `<CallTarget/>` were implemented as:
<MSBuild
Projects="*File-Containing-The-Target-To-Invoke*"
Targets="...Targets..."
/>
Therein lies the problem: by convention, ~everything is using the
`$(BuildDependsOn)` property, and 29568117 altered
`mono-runtimes.targets` so that `$(BuildDependsOn)` would be
explicitly specified, but `mono-runtimes.targets` is `<Import/>`ed by
`bundle.targets`, thus *replacing* the *intended* definition of
`$(BuildDependsOn)` from `bundle.mdproj`.
Thus, `$(BuildDependsOn)` *didn't* include the `CreateBundle` target,
so the `CreateBundle` target was never executed, thus
*no bundle was created or uploaded*.
Doh!
The fix? Remove all use of `<CallTarget/>`. `<CallTarget/>` is a BUG.
Instead, *always* use `<MSBuild/>`, which allows specifying the
correct project file to build from (the `.mdproj`, in our case), so
that the correct "deferred" `ForceBuild` target can be invoked.
Unfortunately, [using the `<MSBuild/> task raised *another* issue][1]:
> this task uses the same MSBuild process to build the child projects.
> The list of already-built targets that can be skipped is shared
> between the parent and child builds.
This means that the
[child build *skips* running the `_GetRuntimesOutputItems` target][2],
which means that *everything breaks* because nothing is built, because
there are no `Inputs` or `Outputs` for anything.
Target _BuildRuntimes:
No input files were specified for target _BuildRuntimes, skipping.
Done building target "_BuildRuntimes" in project "/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/build-tools/mono-runtimes/mono-runtimes.mdproj".
We work around this issue by providing a
`$(_ForceXbuildToNotCacheTargets)` property to the `<MSBuild/>` task
with the value of `DateTime.Now.Ticks`, i.e. a ~constantly changing
value, which should *prevent* the target skipping. (We hope.)
*Additionally*, `msbuild` reported a few errors when referencing
`%(_LibZipTarget.OutputLibraryPath)` item metadata, so fix those
references.
Finally, another aspect of `<MSBuild/>` behavior arose:
The [`MSBuild.Properties`][1] parameter is equivalent to the
`msbuild /p:` parameter, which in turn means that the *value* is
*immutable*; it *can't* be changed (or fixed!) from `.targets` files.
The result being that `<MSBuild/>` use in
`android-toolchain.targets` is *fraught with peril*:
<MSBuild
Projects="..\..\src\Xamarin.Android.Tools.BootstrapTasks\Xamarin.Android.Tools.BootstrapTasks.csproj"
Properties="OutputPath=$(AndroidToolchainDirectory)"
/>
This *looks* reasonable, but `$(OutputPath)` is expected to end with
the directory separator char, and `Microsoft.Common.targets` *tries*
to ensure this:
<OutputPath Condition="'$(OutputPath)' != '' and !HasTrailingSlash('$(OutputPath)')">$(OutputPath)\</OutputPath>
However, since `MSBuild.Properties` values are *immutable*, this
attempt to modify the `$(OutputPath)` property to end with a `\` has
*no effect*, which results in *bizarre* errors later:
error MSB4062: The "Xamarin.Android.BuildTools.PrepTasks.DownloadUri" task
could not be loaded from the assembly $HOME/android-toolchainxa-prep-tasks.dll.
Note the path, `$HOME/android-toolchainxa-prep-tasks.dll`. The path
*should* be `$HOME/android-toolchain/xa-prep-tasks.dll`. What's
missing is...the directory separator char after `$(OutputPath)`.
The fix? Explicitly provide the directory separator character in the
`<MSBuild/>` invocation:
<MSBuild
Projects="..\..\src\Xamarin.Android.Tools.BootstrapTasks\Xamarin.Android.Tools.BootstrapTasks.csproj"
Properties="OutputPath=$(AndroidToolchainDirectory)\"
/>
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/51/consoleText
[1]: https://msdn.microsoft.com/en-us/library/z7f65y0d.aspx
[2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/131/consoleText
2016-09-03 00:13:23 +03:00
|
|
|
<Target Name="Build" DependsOnTargets="$(BuildDependsOn)" />
|
2016-04-20 04:30:00 +03:00
|
|
|
<PropertyGroup>
|
2016-05-06 00:07:05 +03:00
|
|
|
<_SourceTopDir>..\..</_SourceTopDir>
|
|
|
|
|
<_BclFrameworkDir>$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0</_BclFrameworkDir>
|
2016-04-20 04:30:00 +03:00
|
|
|
</PropertyGroup>
|
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>
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<ForceBuildDependsOn>
|
|
|
|
|
_BuildLlvm;
|
|
|
|
|
_InstallLlvm;
|
|
|
|
|
_Autogen;
|
|
|
|
|
_ConfigureRuntimes;
|
|
|
|
|
_BuildRuntimes;
|
|
|
|
|
_InstallRuntimes;
|
|
|
|
|
_InstallBcl;
|
|
|
|
|
_ConfigureCrossRuntimes;
|
|
|
|
|
_BuildCrossRuntimes;
|
|
|
|
|
_InstallCrossRuntimes;
|
|
|
|
|
</ForceBuildDependsOn>
|
|
|
|
|
</PropertyGroup>
|
2016-05-06 00:07:05 +03:00
|
|
|
<Import Project="mono-runtimes.props" />
|
|
|
|
|
<Import Project="mono-runtimes.projitems" />
|
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"/>
|
2016-08-13 03:56:59 +03:00
|
|
|
<_BclAssembly Include="System.IdentityModel.dll"/>
|
2016-05-12 18:23:10 +03:00
|
|
|
<_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"/>
|
2016-07-15 15:49:18 +03:00
|
|
|
<_BclAssembly Include="System.Net.Http.WinHttpHandler.dll"/>
|
2016-05-12 18:23:10 +03:00
|
|
|
<_BclAssembly Include="System.Numerics.dll"/>
|
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"/>
|
2016-05-12 18:23:10 +03:00
|
|
|
<_BclAssembly Include="System.Runtime.Serialization.dll"/>
|
2016-07-15 15:49:18 +03:00
|
|
|
<_BclAssembly Include="System.Security.dll"/>
|
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"/>
|
2016-07-15 15:49:18 +03:00
|
|
|
<_BclAssembly Include="System.Xml.XPath.XmlDocument.dll"/>
|
2016-05-12 18:23:10 +03:00
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<_BclProfileItems Include="@(_BclAssembly->'$(_MonoProfileDir)\%(Identity)')" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
2016-08-17 04:18:15 +03:00
|
|
|
<_BclInstalledItem Include="@(_BclAssembly->'$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0\%(Identity)')" />
|
2016-05-12 18:23:10 +03:00
|
|
|
</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
|
|
|
/>
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
<Exec
|
|
|
|
|
Command="touch -m -t `git log -1 --format=%25cd --date=format-local:%25Y%25m%25d%25H%25M.%25S` Makefile.config.in"
|
|
|
|
|
WorkingDirectory="$(LlvmSourceFullPath)"
|
|
|
|
|
/>
|
[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' " />
|
2016-08-15 00:54:15 +03:00
|
|
|
<_LlvmTargetBinary Include="@(_LlvmRuntime->'$(OutputPath)\%(InstallPath)opt%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' "/>
|
[mono-runtimes] Build AOT+LLVM cross-compilers (#125)
The commit implements building of LLVM and cross-compilers to support
Xamarin.Android/Mono AOT. LLVM and cross-compilers can be built for
both the host platform (Linux and OS/X at the moment) as well as
cross-compiled for 32-bit and 64-bit Windows platforms.
Windows builds are done with MXE toolchain on OS/X and with the packaged
mingw-w64 toolchain on Linux (tested on Ubuntu 16.04 ONLY).
Also introducing a new set of MSBuild properties that contain information
about the host system. Some of those properties (HostOS, HostCC, HostCXX
for instance) have been moved from Configuration.props to better support
auto-detection. A new script, build-tools/scripts/generate-os-info, is
invoked as part of `make prepare` to generate file that contains the
new properties. The generated file is required for the build to work and
is also host-specific (it mustn't be moved between different machines)
Cross compiler builds require access to a configured Mono build tree, in
order to generate C structure offsets header file that is used by the AOT
compilers to properly generate AOT-ed binaries. Therefore, even if a JIT
target is not enabled in the configuration, enabling a cross-compiler for
some target will configure Mono for that JIT target but it will NOT build
it, to save time. To facilitate this, the _MonoRuntimes items defined in
build-tools/mono-runtimes/mono-runtimes.projitems gain an additional metadata
item called `DoBuild` which will be set to `true` if the runtime actually needs
to be built, as opposed to just configured.
MXE builds are disabled on Linux as mingw-w64 works just fine.
A `make prepare` warning is issued for Linux hosts which have the binfmt_misc
module enabled and either Wine of Mono (cli) registered as PE32/PE32+ binary
interpreters. In such instance building of the Windows cross-compilers will
fail because Autotools determine whether software is being cross compiled by
building a test program and attempting to execute it. In normal circumstances
such an attempt will fail, but with Windows cross-compilation and either Wine
or Mono registered to handle the PE32 executables this attempt will succeed
thus causing the cross compilation detection to fail.
Currently to build cross compilers on Linux you need to generate the C structure
offsets header file on OS/X and copy the resulting headers to appropriate places
on Linux. The header files should be placed in
build-tools/mono-runtimes/obj/Debug/cross-*/
directories. The header files are:
{cross-arm,cross-arm-win}/aarch64-v8a-linux-android.h
{cross-arm64,cross-arm64-win}/armv5-none-linux-androideabi.h
{cross-x86,cross-x86-win}/i686-none-linux-android.h
{cross-x86_64,cross-x86_64-win}/x86_64-none-linux-android.h
Offsets header generation doesn't work on Linux atm because of missing support
for it in the Mono utility used to generate the offsets. Hopefully this limitation
will be removed in the near future and a start-to-end build of everything will be
possible on Linux.
It is now mandatory to run at least `make prepare-props` before Xamarin.Android
can be built. The target generates the OS-specific props file which is required
by the build. `make prepare` depends on the target.
2016-07-26 16:27:31 +03:00
|
|
|
|
|
|
|
|
<_LlvmSourceBinary Include="@(_LlvmRuntime->'$(_LlvmOutputDirTop)\%(BuildDir)\Release\bin\llc%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' " />
|
2016-08-15 00:54:15 +03:00
|
|
|
<_LlvmTargetBinary Include="@(_LlvmRuntime->'$(OutputPath)\%(InstallPath)llc%(ExeSuffix)')" Condition=" '%(_LlvmRuntime.InstallBinaries)' == 'true' " />
|
[mono-runtimes] Build AOT+LLVM cross-compilers (#125)
The commit implements building of LLVM and cross-compilers to support
Xamarin.Android/Mono AOT. LLVM and cross-compilers can be built for
both the host platform (Linux and OS/X at the moment) as well as
cross-compiled for 32-bit and 64-bit Windows platforms.
Windows builds are done with MXE toolchain on OS/X and with the packaged
mingw-w64 toolchain on Linux (tested on Ubuntu 16.04 ONLY).
Also introducing a new set of MSBuild properties that contain information
about the host system. Some of those properties (HostOS, HostCC, HostCXX
for instance) have been moved from Configuration.props to better support
auto-detection. A new script, build-tools/scripts/generate-os-info, is
invoked as part of `make prepare` to generate file that contains the
new properties. The generated file is required for the build to work and
is also host-specific (it mustn't be moved between different machines)
Cross compiler builds require access to a configured Mono build tree, in
order to generate C structure offsets header file that is used by the AOT
compilers to properly generate AOT-ed binaries. Therefore, even if a JIT
target is not enabled in the configuration, enabling a cross-compiler for
some target will configure Mono for that JIT target but it will NOT build
it, to save time. To facilitate this, the _MonoRuntimes items defined in
build-tools/mono-runtimes/mono-runtimes.projitems gain an additional metadata
item called `DoBuild` which will be set to `true` if the runtime actually needs
to be built, as opposed to just configured.
MXE builds are disabled on Linux as mingw-w64 works just fine.
A `make prepare` warning is issued for Linux hosts which have the binfmt_misc
module enabled and either Wine of Mono (cli) registered as PE32/PE32+ binary
interpreters. In such instance building of the Windows cross-compilers will
fail because Autotools determine whether software is being cross compiled by
building a test program and attempting to execute it. In normal circumstances
such an attempt will fail, but with Windows cross-compilation and either Wine
or Mono registered to handle the PE32 executables this attempt will succeed
thus causing the cross compilation detection to fail.
Currently to build cross compilers on Linux you need to generate the C structure
offsets header file on OS/X and copy the resulting headers to appropriate places
on Linux. The header files should be placed in
build-tools/mono-runtimes/obj/Debug/cross-*/
directories. The header files are:
{cross-arm,cross-arm-win}/aarch64-v8a-linux-android.h
{cross-arm64,cross-arm64-win}/armv5-none-linux-androideabi.h
{cross-x86,cross-x86-win}/i686-none-linux-android.h
{cross-x86_64,cross-x86_64-win}/x86_64-none-linux-android.h
Offsets header generation doesn't work on Linux atm because of missing support
for it in the Mono utility used to generate the offsets. Hopefully this limitation
will be removed in the near future and a start-to-end build of everything will be
possible on Linux.
It is now mandatory to run at least `make prepare-props` before Xamarin.Android
can be built. The target generates the OS-specific props file which is required
by the build. `make prepare` depends on the target.
2016-07-26 16:27:31 +03:00
|
|
|
</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)"
|
2016-08-17 04:18:15 +03:00
|
|
|
DestinationFiles="@(_LlvmTargetBinary)" />
|
[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
|
|
|
<Touch
|
|
|
|
|
Files="@(_LlvmTargetBinary)" />
|
|
|
|
|
</Target>
|
|
|
|
|
|
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">
|
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)"
|
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)" />
|
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="%(_MonoRuntime.LdFlags)" CFLAGS="%(_MonoRuntime.CFlags)" CXXFLAGS="%(_MonoRuntime.CxxFlags)" CC="%(_MonoRuntime.Cc)" CXX="%(_MonoRuntime.Cxx)" CPP="%(_MonoRuntime.Cpp)" CXXCPP="%(_MonoRuntime.CxxCpp)" LD="%(_MonoRuntime.Ld)" AR="%(_MonoRuntime.Ar)" AS="%(_MonoRuntime.As)" RANLIB="%(_MonoRuntime.RanLib)" STRIP="%(_MonoRuntime.Strip)" DLLTOOL="%(_MonoRuntime.DllTool)" OBJDUMP="%(_MonoRuntime.Objdump)" --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)"
|
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"
|
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>
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
<_RuntimeSource
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)\mono\mini\.libs\%(OutputRuntimeFilename).%(NativeLibraryExtension)')"
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
/>
|
|
|
|
|
<_InstallRuntimeOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
|
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputRuntimeFilename).%(NativeLibraryExtension)')"
|
|
|
|
|
/>
|
|
|
|
|
<_InstallUnstrippedRuntimeOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
|
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputRuntimeFilename).d.%(NativeLibraryExtension)')"
|
|
|
|
|
/>
|
|
|
|
|
<_ProfilerSource
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' And '%(_MonoRuntime.OutputProfilerFilename)' != '' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)\mono\profiler\.libs\%(OutputProfilerFilename).%(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
|
|
|
/>
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
<_InstallProfilerOutput
|
|
|
|
|
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)')"
|
|
|
|
|
/>
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
<_InstallUnstrippedProfilerOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' And '%(_MonoRuntime.OutputProfilerFilename)' != '' "
|
|
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputProfilerFilename).d.%(NativeLibraryExtension)')"
|
|
|
|
|
/>
|
|
|
|
|
<_MonoPosixHelperSource
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' And '%(_MonoRuntime.OutputMonoPosixHelperFilename)' != '' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)\support\.libs\%(OutputMonoPosixHelperFilename).%(NativeLibraryExtension)')"
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
/>
|
|
|
|
|
<_InstallMonoPosixHelperOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' And '%(_MonoRuntime.OutputMonoPosixHelperFilename)' != '' "
|
|
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputMonoPosixHelperFilename).%(NativeLibraryExtension)')"
|
|
|
|
|
/>
|
|
|
|
|
<_InstallUnstrippedMonoPosixHelperOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' And '%(_MonoRuntime.OutputMonoPosixHelperFilename)' != '' "
|
|
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(Identity)\%(OutputMonoPosixHelperFilename).d.%(NativeLibraryExtension)')"
|
|
|
|
|
/>
|
[mono-runtimes] "Install" eglib headers into $prefix/include (#164)
Context: https://github.com/xamarin/xamarin-android/pull/162
PR #162 tries to use the mono bundle (fbfd676c) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)
[PR #162 currently fails][0] when building `src/monodroid`:
Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
...
[armeabi-v7a] Compile thumb : monodroid <= nl.c
/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
In file included from jni/../../../external/mono/support/nl.h:3:0,
from jni/../../../external/mono/support/nl.c:14:
jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
#include <eglib-config.h>
^
compilation terminated.
`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)
Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.
This should allow a future PR #162 fix to build, as all required
generated files will be present within the bundle.
Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
2016-08-14 15:52:04 +03:00
|
|
|
<_RuntimeEglibHeaderSource
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)\eglib\config.h');@(_MonoRuntime->'$(IntermediateOutputPath)\%(Identity)\eglib\src\eglib-config.h')"
|
[mono-runtimes] "Install" eglib headers into $prefix/include (#164)
Context: https://github.com/xamarin/xamarin-android/pull/162
PR #162 tries to use the mono bundle (fbfd676c) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)
[PR #162 currently fails][0] when building `src/monodroid`:
Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
...
[armeabi-v7a] Compile thumb : monodroid <= nl.c
/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
In file included from jni/../../../external/mono/support/nl.h:3:0,
from jni/../../../external/mono/support/nl.c:14:
jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
#include <eglib-config.h>
^
compilation terminated.
`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)
Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.
This should allow a future PR #162 fix to build, as all required
generated files will be present within the bundle.
Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
2016-08-14 15:52:04 +03:00
|
|
|
/>
|
|
|
|
|
<_RuntimeEglibHeaderOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="@(_MonoRuntime->'$(OutputPath)\include\%(Identity)\eglib\config.h');@(_MonoRuntime->'$(OutputPath)\include\%(Identity)\eglib\eglib-config.h')"
|
[mono-runtimes] "Install" eglib headers into $prefix/include (#164)
Context: https://github.com/xamarin/xamarin-android/pull/162
PR #162 tries to use the mono bundle (fbfd676c) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)
[PR #162 currently fails][0] when building `src/monodroid`:
Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
...
[armeabi-v7a] Compile thumb : monodroid <= nl.c
/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
In file included from jni/../../../external/mono/support/nl.h:3:0,
from jni/../../../external/mono/support/nl.c:14:
jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
#include <eglib-config.h>
^
compilation terminated.
`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)
Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.
This should allow a future PR #162 fix to build, as all required
generated files will be present within the bundle.
Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
2016-08-14 15:52:04 +03:00
|
|
|
/>
|
2016-08-15 00:54:15 +03:00
|
|
|
<_MonoConstsSource
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
|
|
|
|
Include="$(MonoSourceFullPath)\mcs\build\common\Consts.cs"
|
|
|
|
|
/>
|
|
|
|
|
<_MonoConstsOutput
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'True' "
|
2016-08-17 04:18:15 +03:00
|
|
|
Include="$(OutputPath)\include\Consts.cs"
|
2016-08-15 00:54:15 +03:00
|
|
|
/>
|
2016-08-17 04:18:15 +03:00
|
|
|
<_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>
|
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"
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
Inputs="@(_RuntimeBuildStamp)"
|
|
|
|
|
Outputs="@(_RuntimeSource);@(_ProfilerSource);@(_MonoPosixHelperSource);@(_BclProfileItems)">
|
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)"
|
2016-04-20 04:30:00 +03:00
|
|
|
/>
|
2016-04-23 14:54:47 +03:00
|
|
|
<Touch
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
Files="@(_RuntimeSource);@(_ProfilerSource);@(_MonoPosixHelperSource);@(_BclProfileItems)"
|
2016-04-23 14:54:47 +03:00
|
|
|
/>
|
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"
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
Inputs="@(_RuntimeSource);@(_ProfilerSource);@(_MonoPosixHelperSource)"
|
|
|
|
|
Outputs="@(_InstallRuntimesOutput);@(_InstallProfilerOutput);@(_InstallMonoPosixHelperOutput)">
|
[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
|
|
|
<MakeDir
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
|
|
|
|
|
Directories="$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)"
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
/>
|
[mono-runtimes] "Install" eglib headers into $prefix/include (#164)
Context: https://github.com/xamarin/xamarin-android/pull/162
PR #162 tries to use the mono bundle (fbfd676c) to avoid rebuilding
mono on subsequent builds (when the mono commit hasn't changed), in
order to speed up the Jenkins build process (currently tracking at
~3.5 *hours* for a non-PR build...)
[PR #162 currently fails][0] when building `src/monodroid`:
Executing: /Users/builder/android-toolchain/ndk/ndk-build CONFIGURATION=Debug NDK_LIBS_OUT=./libs/Debug NDK_OUT=./obj/Debug V=1
...
[armeabi-v7a] Compile thumb : monodroid <= nl.c
/Users/builder/android-toolchain/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o.d -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib -Ijni/../../../build-tools/mono-runtimes/obj/Debug/armeabi-v7a/eglib/src -Ijni/../../../external/mono/eglib/src -Ijni/zip -Ijni -DANDROID -ggdb3 -O0 -fno-omit-frame-pointer -std=c99 -DHAVE_LINUX_NETLINK_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -D_REENTRANT -DPLATFORM_ANDROID -DANDROID -DLINUX -Dlinux -D__linux_ -DHAVE_CONFIG_H -DJI_DLL_EXPORT -DMONO_DLL_EXPORT -I/libmonodroid/zip -I/include -I/include/eglib -mandroid -fno-strict-aliasing -ffunction-sections -fomit-frame-pointer -funswitch-loops -finline-limit=300 -fvisibility=hidden -fstack-protector -Wa,--noexecstack -Wformat -Werror=format-security -DDEBUG=1 -Wa,--noexecstack -Wformat -Werror=format-security -isystem /Users/builder/android-toolchain/ndk/platforms/android-9/arch-arm/usr/include -c jni/../../../external/mono/support/nl.c -o ./obj/Debug/local/armeabi-v7a/objs/monodroid/__/__/__/external/mono/support/nl.o
In file included from jni/../../../external/mono/support/nl.h:3:0,
from jni/../../../external/mono/support/nl.c:14:
jni/../../../external/mono/eglib/src/glib.h:18:26: fatal error: eglib-config.h: No such file or directory
#include <eglib-config.h>
^
compilation terminated.
`src/monodroid` fails to build because it requires build artifacts
located in
`build-tools/mono-runtimes/obj/$(Configuration)/%(Identity)/eglib`,
which doesn't exist when the mono bundle is being used (because we
never built mono!)
Fix this issue by updating the `_InstallRuntimes` target in
`mono-runtimes.targets` to copy the generated eglib header files into
`bin/$(Configuration)/include/%(Identity)/eglib`, and update
`bundle.targets` so that the `include` directory is also included in
the mono bundle.
This should allow a future PR #162 fix to build, as all required
generated files will be present within the bundle.
Additionally, add the `$(HostOS)` and a version number to the bundle
filename, now `-v1`, to note that the structure of the bundle has
changed, *without* a corresponding mono, llvm, or libzip commit bump.
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/61/
2016-08-14 15:52:04 +03:00
|
|
|
<MakeDir
|
|
|
|
|
Condition=" '%(_MonoRuntime.DoBuild)' == 'true' "
|
|
|
|
|
Directories="$(OutputPath)\include\%(_MonoRuntime.Identity)\eglib"
|
|
|
|
|
/>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_RuntimeEglibHeaderSource)"
|
|
|
|
|
DestinationFiles="@(_RuntimeEglibHeaderOutput)"
|
|
|
|
|
/>
|
2016-08-15 00:54:15 +03:00
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_MonoConstsSource)"
|
|
|
|
|
DestinationFiles="@(_MonoConstsOutput)"
|
|
|
|
|
/>
|
2016-04-20 04:30:00 +03:00
|
|
|
<Copy
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
SourceFiles="@(_RuntimeSource)"
|
|
|
|
|
DestinationFiles="@(_InstallRuntimeOutput)"
|
2016-04-20 04:30:00 +03:00
|
|
|
/>
|
|
|
|
|
<Copy
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
SourceFiles="@(_RuntimeSource)"
|
|
|
|
|
DestinationFiles="@(_InstallUnstrippedRuntimeOutput)"
|
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=""%(_MonoRuntime.Strip)" %(_MonoRuntime.StripFlags) "$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)\%(_MonoRuntime.OutputRuntimeFilename).%(_MonoRuntime.NativeLibraryExtension)""
|
2016-04-20 04:30:00 +03:00
|
|
|
/>
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_ProfilerSource)"
|
|
|
|
|
DestinationFiles="@(_InstallProfilerOutput)"
|
|
|
|
|
/>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_ProfilerSource)"
|
|
|
|
|
DestinationFiles="@(_InstallUnstrippedProfilerOutput)"
|
|
|
|
|
/>
|
|
|
|
|
<Exec
|
|
|
|
|
Condition=" '$(Configuration)' != 'Debug' And '%(_MonoRuntime.DoBuild)' == 'true' And '%(_MonoRuntime.OutputProfilerFilename)' != '' "
|
|
|
|
|
Command=""%(_MonoRuntime.Strip)" %(_MonoRuntime.StripFlags) "$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)\%(_MonoRuntime.OutputProfilerFilename).%(_MonoRuntime.NativeLibraryExtension)""
|
|
|
|
|
/>
|
|
|
|
|
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_MonoPosixHelperSource)"
|
|
|
|
|
DestinationFiles="@(_InstallMonoPosixHelperOutput)"
|
|
|
|
|
/>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_MonoPosixHelperSource)"
|
|
|
|
|
DestinationFiles="@(_InstallUnstrippedMonoPosixHelperOutput)"
|
|
|
|
|
/>
|
|
|
|
|
<Exec
|
|
|
|
|
Condition=" '$(Configuration)' != 'Debug' And '%(_MonoRuntime.DoBuild)' == 'true' And '%(_MonoRuntime.OutputMonoPosixHelperFilename)' != '' "
|
|
|
|
|
Command=""%(_MonoRuntime.Strip)" %(_MonoRuntime.StripFlags) "$(OutputPath)\lib\xbuild\Xamarin\Android\lib\%(_MonoRuntime.Identity)\%(_MonoRuntime.OutputMonoPosixHelperFilename).%(_MonoRuntime.NativeLibraryExtension)""
|
|
|
|
|
/>
|
2016-04-20 04:30:00 +03:00
|
|
|
<Touch
|
[build] Build the monodroid-profile BCL assemblies reliably (#135)
Commit 37b5fd51 broke `make jenkins` (and possible `make all`?)
through the introduction of the `%(_MonoRuntime.DoBuild)` metadata:
`%(_MonoRuntime.DoBuild)` wasn't added everywhere required.
In particular, the `host-Darwin` item didn't gain `<DoBuild/>`,
meaning *`host-Darwin` wasn't built*. This in turn meant that the
monodroid BCL wasn't built (!) which caused a build break much later
within `src/Mono.Android`:
Executing: mono .../xamarin-android/external/Java.Interop/bin/Debug/jcw-gen.exe
-o ".../xamarin-android/src/Mono.Android/obj/Debug/android-23/jcw/src"
-L ".../xamarin-androidg/lib/xbuild-frameworks/MonoAndroid/v6.0/"
-L ".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/../v1.0/"
-L ".../xamarin-android/src/Mono.Android/../../MonoAndroid/v6.0/../v1.0/Facades"
".../xamarin-android/src/Mono.Android/../../bin/Debug/lib/xbuild-frameworks/MonoAndroid/v6.0/Mono.Android.dll"
jcw-gen: Could not load assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Perhaps it doesn't exist in the Mono for Android profile?
`mscorlib.dll` couldn't be found because it wasn't *built*, nor
installed into `bin/Debug/lib/xbuild-frameworks/MonoAndroid/v1.0`.
Additionally, fully building the AOT cross compilers requires adding
`mxe-Win32` to `$(ALL_HOST_ABIS)`, otherwise e.g. `win-armeabi` fails
to build because `arm_dpimacros.h` doesn't exist (as `arm_dpimacros.h`
is built by `mxe-Win32`):
Error parsing '.../xamarin-android/external/mono/mono/metadata/metadata-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Error parsing '.../xamarin-android/external/mono/mono/mini/mini-cross-helpers.c'
.../xamarin-android/external/mono/mono/arch/arm/arm-codegen.h(937,10): fatal: 'mono/arch/arm/arm_dpimacros.h' file not found
Unhandled Exception:
System.Exception: Expected to find struct definition for MonoObject
Fix the `mono-runtimes.mdproj` build so that it doesn't re-execute
targets when not necessary, by "rolling" with xbuild limitations and
refactoring item groups as appropriate. In particular, xbuild doesn't
like referencing item metadata within a `//Target/@Outputs` that in
turn references a property group:
<PropertyGroup>
<V>Value</v>
</PropertyGroup>
<ItemGroup>
<Item Include="Something">
<Metadata>$(V)</Metadata>
</Item>
</ItemGroup>
<Target Name="Example" Inputs="..."
Outputs="%(Item.Metadata)">
...
</Target>
Whenever the `Example` target is run, it will *always* run, even if
`Value` exists, because `xbuild` perceives the
`//Target[@Name='Example']/@Outputs` value as being
`$(V)`, *not* `Value`, which is wonderfully broken.
To compensate, Don't Do That™; in particular, item metadata used
within `//Target/@Outputs` *must* be hardcoded and not contain a
property reference. This "hardcoding" removes the need for the
`$(_Cross*ffsetsHeaderFile)` properties, so remove them.
Remove `System.Net.Http.WebRequest.dll` from `@(_BclAssembly)`, as it
is no longer built in the monodroid profile; requiring it as an output
means that the "host" mono build is *always* built, which isn't needed.
Improve the `_BuildRuntimes` and `_InstallRuntimes` targets so that
their referenced files aren't *so* repetitive, in particular by
"splitting out" `@(_RuntimeLibraries)` into `@(_RuntimeSource)`,
`@(_ProfilerSource)`, and `@(_MonoPosixHelperSource)`. This allows
more intelligently `strip`ing the native libraries in the Release
configuration, while also maintaining generation of the `.d.so` files.
2016-07-28 13:24:18 +03:00
|
|
|
Files="@(_InstallRuntimesOutput);@(_InstallProfilerOutput);@(_InstallMonoPosixHelperOutput)"
|
2016-04-20 04:30:00 +03:00
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
<Target Name="_InstallBcl"
|
2016-05-12 18:23:10 +03:00
|
|
|
Inputs="@(_BclProfileItems)"
|
2016-08-17 04:18:15 +03:00
|
|
|
Outputs="@(_BclInstalledItem);$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0\RedistList\FrameworkList.xml">
|
2016-05-06 00:07:05 +03:00
|
|
|
<MakeDir Directories="$(_BclFrameworkDir)" />
|
|
|
|
|
<MakeDir Directories="$(_BclFrameworkDir)\RedistList" />
|
|
|
|
|
<MakeDir Directories="$(_BclFrameworkDir)\Facades" />
|
2016-04-20 04:30:00 +03:00
|
|
|
<ItemGroup>
|
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*" />
|
2016-05-12 18:23:10 +03:00
|
|
|
<_Assemblies Include="$(_MonoProfileDir)\*.dll" />
|
|
|
|
|
<_Facades Include="$(_MonoProfileDir)\Facades\*.dll" />
|
2016-04-20 04:30:00 +03:00
|
|
|
</ItemGroup>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_Assemblies)"
|
2016-05-06 00:07:05 +03:00
|
|
|
DestinationFolder="$(_BclFrameworkDir)"
|
2016-04-20 04:30:00 +03:00
|
|
|
/>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_Facades)"
|
2016-05-06 00:07:05 +03:00
|
|
|
DestinationFolder="$(_BclFrameworkDir)\Facades"
|
|
|
|
|
/>
|
|
|
|
|
<Copy
|
|
|
|
|
SourceFiles="@(_FSharp)"
|
|
|
|
|
DestinationFolder="$(_BclFrameworkDir)"
|
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)"
|
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="<FileList Redist="MonoAndroid" Name="Xamarin.Android Base Class Libraries">" />
|
|
|
|
|
<FrameworkList Include="</FileList>" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<WriteLinesToFile
|
2016-08-17 04:18:15 +03:00
|
|
|
File="$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0\RedistList\FrameworkList.xml"
|
[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
|
|
|
Lines="@(FrameworkList)"
|
|
|
|
|
Overwrite="True"
|
|
|
|
|
/>
|
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"
|
2016-08-17 04:18:15 +03:00
|
|
|
Outputs="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\Makefile;$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\.stamp"
|
[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=" '@(_MonoCrossRuntime)' != '' ">
|
|
|
|
|
<MakeDir Directories="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)" />
|
|
|
|
|
<Exec
|
|
|
|
|
Command="%(_MonoCrossRuntime.ConfigureEnvironment) $(MonoSourceFullPath)\configure LDFLAGS="%(_MonoCrossRuntime.LdFlags)" CFLAGS="%(_MonoCrossRuntime.CFlags)" CXXFLAGS="%(_MonoCrossRuntime.CxxFlags)" CC="%(_MonoCrossRuntime.Cc)" CXX="%(_MonoCrossRuntime.Cxx)" CPP="%(_MonoCrossRuntime.Cpp)" CXXCPP="%(_MonoCrossRuntime.CxxCpp)" LD="%(_MonoCrossRuntime.Ld)" AR="%(_MonoCrossRuntime.Ar)" AS="%(_MonoCrossRuntime.As)" RANLIB="%(_MonoCrossRuntime.RanLib)" STRIP="%(_MonoCrossRuntime.Strip)" DLLTOOL="%(_MonoCrossRuntime.DllTool)" OBJDUMP="%(_MonoCrossRuntime.Objdump)" --cache-file=..\%(_MonoCrossRuntime.Identity).config.cache %(_MonoCrossRuntime.ConfigureFlags)"
|
2016-08-17 04:18:15 +03:00
|
|
|
WorkingDirectory="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)"
|
[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
|
|
|
/>
|
|
|
|
|
<Touch
|
2016-08-17 04:18:15 +03:00
|
|
|
Files="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\.stamp"
|
[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
|
|
|
AlwaysCreate="True"
|
|
|
|
|
/>
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<Target Name="_GenerateCrossOffsetHeaderFiles"
|
|
|
|
|
Inputs="$(MonoSourceFullPath)\configure"
|
2016-08-17 04:18:15 +03:00
|
|
|
Outputs="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\%(_MonoCrossRuntime.TargetAbi).h"
|
[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=" '$(HostOS)' != 'Linux' And '@(_MonoCrossRuntime)' != '' ">
|
|
|
|
|
<Exec
|
|
|
|
|
Command="make $(_AotOffsetsDumperName)"
|
|
|
|
|
WorkingDirectory="$(_AotOffsetsDumperSourceDir)"
|
|
|
|
|
/>
|
|
|
|
|
<Exec
|
2016-08-17 04:18:15 +03:00
|
|
|
Command="MONO_PATH=$(_AotOffsetsDumperSourceDir)\CppSharp $(ManagedRuntime) $(_AotOffsetsDumperSourceDir)\$(_AotOffsetsDumperName) --xamarin-android --android-ndk="$(AndroidNdkFullPath)" --mono="$(MonoSourceFullPath)" --monodroid="$(XamarinAndroidSourcePath)" --abi="%(_MonoCrossRuntime.TargetAbi)" --out="$(MSBuildThisFileDirectory)$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)""
|
|
|
|
|
WorkingDirectory="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)"
|
[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
|
|
|
/>
|
|
|
|
|
<Touch
|
2016-08-17 04:18:15 +03:00
|
|
|
Files="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\%(_MonoCrossRuntime.OffsetsHeaderFile)"
|
[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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- 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"
|
2016-08-17 04:18:15 +03:00
|
|
|
Inputs="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\.stamp"
|
|
|
|
|
Outputs="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
|
[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=" '@(_MonoCrossRuntime)' != '' ">
|
2016-08-17 04:18:15 +03:00
|
|
|
<Message Text="Building %(_MonoCrossRuntime.Identity) in $(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)"/>
|
[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
|
|
|
<Exec
|
|
|
|
|
Command="%(_MonoCrossRuntime.BuildEnvironment) make $(MakeConcurrency)"
|
2016-08-17 04:18:15 +03:00
|
|
|
WorkingDirectory="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)"
|
[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
|
|
|
/>
|
|
|
|
|
<Touch
|
2016-08-17 04:18:15 +03:00
|
|
|
Files="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
|
[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>
|
|
|
|
|
|
|
|
|
|
<!-- 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"
|
2016-08-17 04:18:15 +03:00
|
|
|
Inputs="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
|
|
|
|
|
Outputs="$(OutputPath)\%(_MonoCrossRuntime.InstallPath)%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
|
[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=" '@(_MonoCrossRuntime)' != '' ">
|
2016-08-17 04:18:15 +03:00
|
|
|
<MakeDir Directories="$(OutputPath)\bin\" />
|
[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
|
|
|
<Copy
|
2016-08-17 04:18:15 +03:00
|
|
|
SourceFiles="$(IntermediateOutputPath)\%(_MonoCrossRuntime.Identity)\mono\mini\mono-sgen%(_MonoCrossRuntime.ExeSuffix)"
|
|
|
|
|
DestinationFiles="$(OutputPath)\%(_MonoCrossRuntime.InstallPath)%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
|
[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
|
|
|
/>
|
|
|
|
|
<Touch
|
2016-08-17 04:18:15 +03:00
|
|
|
Files="$(OutputPath)\%(_MonoCrossRuntime.InstallPath)%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
|
[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>
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
<Target Name="GetMonoBundleItems"
|
2016-08-17 04:18:15 +03:00
|
|
|
DependsOnTargets="_GetRuntimesOutputItems;_PrepareLlvmItems">
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
<ItemGroup>
|
|
|
|
|
<BundleItem Include="@(_BclInstalledItem)" />
|
2016-08-17 04:18:15 +03:00
|
|
|
<BundleItem Include="$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0\Facades\*.dll*" />
|
|
|
|
|
<BundleItem Include="$(OutputPath)\lib\xbuild-frameworks\MonoAndroid\v1.0\RedistList\FrameworkList.xml" />
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
<BundleItem Include="@(_InstallRuntimeOutput)" />
|
|
|
|
|
<BundleItem Include="@(_InstallUnstrippedRuntimeOutput)" />
|
|
|
|
|
<BundleItem Include="@(_InstallProfilerOutput)" />
|
|
|
|
|
<BundleItem Include="@(_InstallUnstrippedProfilerOutput)" />
|
|
|
|
|
<BundleItem Include="@(_InstallMonoPosixHelperOutput)" />
|
|
|
|
|
<BundleItem Include="@(_InstallUnstrippedMonoPosixHelperOutput)" />
|
|
|
|
|
<BundleItem Include="@(_RuntimeEglibHeaderOutput)" />
|
2016-08-17 04:18:15 +03:00
|
|
|
<BundleItem Include="@(_LlvmTargetBinary)" />
|
|
|
|
|
<BundleItem Include="$(OutputPath)\%(_MonoCrossRuntime.InstallPath)%(_MonoCrossRuntime.CrossMonoName)%(_MonoCrossRuntime.ExeSuffix)"
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
Condition=" '@(_MonoCrossRuntime)' != '' "
|
|
|
|
|
/>
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
</Target>
|
|
|
|
|
<Target Name="ForceBuild"
|
|
|
|
|
DependsOnTargets="GetMonoBundleItems;$(ForceBuildDependsOn)"
|
|
|
|
|
Inputs="$(MonoSourceFullPath)\autogen.sh;$(LlvmSourceFullPath)\Makefile.config.in"
|
|
|
|
|
Outputs="@(BundleItem)">
|
|
|
|
|
</Target>
|
|
|
|
|
<Target Name="_BuildUnlessCached"
|
|
|
|
|
DependsOnTargets="_SetAutogenShTimeToLastCommitTimestamp;GetMonoBundleItems"
|
|
|
|
|
Inputs="$(MonoSourceFullPath)\autogen.sh;$(LlvmSourceFullPath)\Makefile.config.in"
|
|
|
|
|
Outputs="@(BundleItem)">
|
[bundle] Create the bundle (#206)
Using the mono bundle (29568117, 57b18c27, ffe39776) didn't work as
well as intended, because *using* the mono bundle requires that the
bundle (1) *exist*, and (2) contain expected outputs.
Neither of which is true:
$ curl -o x.zip https://xamjenkinsartifact.blob.core.windows.net/xamarin-android/xamarin-android/bin/BuildDebug/bundle-v3-Debug-Darwin-libzip=1d8b1ac,llvm=8b1520c,mono=2c13a95.zip
$ file x.zip
x.zip: XML document text
$ cat x.zip
<?xml version="1.0" encoding="utf-8"?>
<Error>
<Code>BlobNotFound</Code>
<Message>The specified blob does not exist.
RequestId:f1722d1f-0001-0098-3fdd-fe4670000000
Time:2016-08-25T14:31:09.4102289Z
</Message>
</Error>
That is, the URL "exists", but it doesn't contain anything *useful*.
The bundle doesn't exist, in turn, because [*it isn't created*][0]:
Project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/build-tools/bundle/bundle.mdproj" (default target(s)):
...
Done building project "/Users/builder/jenkins/workspace/xamarin-android/xamarin-android/build-tools/bundle/bundle.mdproj".
What's *missing* from the log file is any mention of the
`CreateBundle` target, which *creates the bundle*. Since the
`CreateBundle` target isn't invoked, *there is no bundle*, and thus
there's *nothing to upload*, and thus there's *nothing to download*,
either.
Why isn't the `CreateBundle` target executed? Because of property
group "overwrites". But first, a step back.
Remember 57b18c27?
> I *assume* that this is due to `<CallTarget/>` being "flakey" within
> xbuild (it passes the file containing the target to `<MSBuild/>`!),
> and *somehow* in that "flakiness" `$(OutputPath)` doesn't end with
> `\`, *which it should*, because `Microsoft.Common.targets` will
> automatically append `\` to `$(OutputPath)`.
Let's elaborate on the "flakiness" of xbuild: The `<CallTarget/>` task
doesn't *just* invoke the specified target. Rather, xbuild will
*reload the file containing the target*, "stand-alone", and execute
the target. It's "as if" `<CallTarget/>` were implemented as:
<MSBuild
Projects="*File-Containing-The-Target-To-Invoke*"
Targets="...Targets..."
/>
Therein lies the problem: by convention, ~everything is using the
`$(BuildDependsOn)` property, and 29568117 altered
`mono-runtimes.targets` so that `$(BuildDependsOn)` would be
explicitly specified, but `mono-runtimes.targets` is `<Import/>`ed by
`bundle.targets`, thus *replacing* the *intended* definition of
`$(BuildDependsOn)` from `bundle.mdproj`.
Thus, `$(BuildDependsOn)` *didn't* include the `CreateBundle` target,
so the `CreateBundle` target was never executed, thus
*no bundle was created or uploaded*.
Doh!
The fix? Remove all use of `<CallTarget/>`. `<CallTarget/>` is a BUG.
Instead, *always* use `<MSBuild/>`, which allows specifying the
correct project file to build from (the `.mdproj`, in our case), so
that the correct "deferred" `ForceBuild` target can be invoked.
Unfortunately, [using the `<MSBuild/> task raised *another* issue][1]:
> this task uses the same MSBuild process to build the child projects.
> The list of already-built targets that can be skipped is shared
> between the parent and child builds.
This means that the
[child build *skips* running the `_GetRuntimesOutputItems` target][2],
which means that *everything breaks* because nothing is built, because
there are no `Inputs` or `Outputs` for anything.
Target _BuildRuntimes:
No input files were specified for target _BuildRuntimes, skipping.
Done building target "_BuildRuntimes" in project "/Users/builder/jenkins/workspace/xamarin-android-pr-builder/xamarin-android/build-tools/mono-runtimes/mono-runtimes.mdproj".
We work around this issue by providing a
`$(_ForceXbuildToNotCacheTargets)` property to the `<MSBuild/>` task
with the value of `DateTime.Now.Ticks`, i.e. a ~constantly changing
value, which should *prevent* the target skipping. (We hope.)
*Additionally*, `msbuild` reported a few errors when referencing
`%(_LibZipTarget.OutputLibraryPath)` item metadata, so fix those
references.
Finally, another aspect of `<MSBuild/>` behavior arose:
The [`MSBuild.Properties`][1] parameter is equivalent to the
`msbuild /p:` parameter, which in turn means that the *value* is
*immutable*; it *can't* be changed (or fixed!) from `.targets` files.
The result being that `<MSBuild/>` use in
`android-toolchain.targets` is *fraught with peril*:
<MSBuild
Projects="..\..\src\Xamarin.Android.Tools.BootstrapTasks\Xamarin.Android.Tools.BootstrapTasks.csproj"
Properties="OutputPath=$(AndroidToolchainDirectory)"
/>
This *looks* reasonable, but `$(OutputPath)` is expected to end with
the directory separator char, and `Microsoft.Common.targets` *tries*
to ensure this:
<OutputPath Condition="'$(OutputPath)' != '' and !HasTrailingSlash('$(OutputPath)')">$(OutputPath)\</OutputPath>
However, since `MSBuild.Properties` values are *immutable*, this
attempt to modify the `$(OutputPath)` property to end with a `\` has
*no effect*, which results in *bizarre* errors later:
error MSB4062: The "Xamarin.Android.BuildTools.PrepTasks.DownloadUri" task
could not be loaded from the assembly $HOME/android-toolchainxa-prep-tasks.dll.
Note the path, `$HOME/android-toolchainxa-prep-tasks.dll`. The path
*should* be `$HOME/android-toolchain/xa-prep-tasks.dll`. What's
missing is...the directory separator char after `$(OutputPath)`.
The fix? Explicitly provide the directory separator character in the
`<MSBuild/>` invocation:
<MSBuild
Projects="..\..\src\Xamarin.Android.Tools.BootstrapTasks\Xamarin.Android.Tools.BootstrapTasks.csproj"
Properties="OutputPath=$(AndroidToolchainDirectory)\"
/>
[0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/51/consoleText
[1]: https://msdn.microsoft.com/en-us/library/z7f65y0d.aspx
[2]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-pr-builder/131/consoleText
2016-09-03 00:13:23 +03:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<_Now>$([System.DateTime]::Now.Ticks)</_Now>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
<MSBuild
|
|
|
|
|
Projects="$(MSBuildThisFileDirectory)\mono-runtimes.mdproj"
|
|
|
|
|
Properties="_ForceXbuildToNotCacheTargets=$(_Now)"
|
|
|
|
|
Targets="ForceBuild"
|
|
|
|
|
/>
|
[xa-prep-tasks] Use the Mono bundle (#162)
Context: https://github.com/xamarin/xamarin-android/commit/fbfd676c102c63e4e06e750857b178725e33450c
Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676c.
This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676c, but first, a simple question:
What should download the mono bundle?
There are two plausible answers:
1. `make prepare` can (somehow) handle it.
2. MSBuild can (somehow) handle it.
Both are plausible. The problem with using `make` targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, `make` isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (`NMAKE` is, but the Makefiles in this project are not
compatible with `NMAKE`.)
Which brings us to MSBuild (2): can it handle the task?
To tackle that, we need to be able to have an MSBuild task project
which has *no dependencies*, so that it can download and extract the
mono bundle *before anything else runs*, as it may be downloading
contents which mean that other projects don't *need* to run.
The need for a "pre-bootstrap" task assembly -- called `xa-prep-tasks`
-- thus "undoes" *some* of the logic regarding `libzip-windows.mdproj`
and the `<Zip/>` task from fbfd676c: it isn't *possible* to rely on
`libzip` from a "pre-build" state, as `libzip` is one of the things in
the mono bundle, so now we need *two* "bootstrap" task assemblies:
one without a `libzip` dependency -- `xa-prep-tasks.dll` -- and one
*with* a `libzip` dependency --
`Xamarin.Android.Tools.BootstrapTasks.dll`
Move tasks which don't currently require `libzip` -- or won't in the
future, or laziness -- from `Xamarin.Android.Tools.BootstrapTasks.dll`
and move them into `xa-prep-tasks.dll`.
With that architectural compromise in place, add `xa-prep-tasks` as a
`@(ProjectReference)` to various projects to help ensure it's built
*first*, and rearchitect `bundle.mdproj` so that
`xa-prep-tasks.targets` and `bundle.targets` can use the same targets
to compute the bundle filename, now in
`build-tools/bundle/bundle-path.targets`.
Add a post-build step to `xa-prep-tasks.csproj` which downloads and
extracts the expected mono bundle.
One "problem" (feature?) is that the new `<SystemUnzip/>` task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 *anyway* -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're *also* ignoring any checking for invalid
downloads, which is something we should address in the future.
Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.
2016-08-16 23:02:48 +03:00
|
|
|
</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>
|
2016-04-20 04:30:00 +03:00
|
|
|
</Project>
|
