[Mono.Android] Import from monodroid/3e934261
(*Now* things are starting to come together...)
One of the important infrastructural pieces of Xamarin.Android is
Mono.Android.dll, a "binding" for the Android SDK `android.jar` file.
Bindings are generated by using the `generator` tool from
Java.Interop, along with tools/jnienv-gen, and various other programs.
This in turn requires adding a git submodule for Java.Interop.
Stitch all these pieces together so that we can take an
*API description* (stored in Profiles\api-*.xml.in) and generate a
binding for that API description.
The generated files are located in
obj\$(Configuration)\android-$(ApiLevel), and the resulting
Mono.Android.dll is copied to
$(topdir)\bin\$(Configuration)\xbuild-frameworks\MonoAndroid\$(XAFrameworkVersion).
One SNAFU: currently, Mono.Android.csproj conditinally <Import/>s a
Mono.Android.projitems file generated by Java.Interop's generator
tool, which contains a list of all the generated files.
When the project is first loaded, Mono.Android.projitems will not
exist, so on that initial build, source code will be generated but
xbuild won't re-read Mono.Android.projitems (once it exists). This
will result in a failing build.
Simply rebuild the project to get a valid build, or use the `make all`
Makefile target.
2016-04-21 03:50:21 +03:00
|
|
|
[submodule "external/Java.Interop"]
|
|
|
|
|
path = external/Java.Interop
|
2016-05-11 20:05:12 +03:00
|
|
|
url = https://github.com/xamarin/java.interop.git
|
|
|
|
|
branch = master
|
|
|
|
|
[submodule "external/mono"]
|
|
|
|
|
path = external/mono
|
|
|
|
|
url = https://github.com/mono/mono.git
|
2016-07-14 17:04:03 +03:00
|
|
|
branch = mono-4.6.0-branch
|
[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
|
|
|
[submodule "external/mxe"]
|
|
|
|
|
path = external/mxe
|
|
|
|
|
url = https://github.com/xamarin/mxe.git
|
|
|
|
|
branch = xamarin
|
2016-06-10 00:03:31 +03:00
|
|
|
[submodule "external/sqlite"]
|
|
|
|
|
path = external/sqlite
|
|
|
|
|
url = https://github.com/xamarin/sqlite.git
|
2016-06-20 18:06:58 +03:00
|
|
|
[submodule "external/opentk"]
|
|
|
|
|
path = external/opentk
|
|
|
|
|
url = https://github.com/mono/opentk.git
|
|
|
|
|
branch = master
|
[Xamarin.Android.Build.Tasks] Use libZipSharp to build the .apk (#89)
Commit 4ec06ac9 *broke* generation of `.apk` files when migrating
from `Ionic.Zip.dll` to `System.IO.Compression` because this:
apk.AddFile (assembly.ItemSpec, "assemblies", compressionLevel: CompressionLevel.NoCompression);
doesn't work the way we thought/hoped it would.
Specifically, we require that assemblies be *stored*, uncompressed,
within the `.apk`, as we **mmap**(2) the `.apk` and hand off the
memory addresses of the loaded assemblies to mono for execution.
`CompressionLevel.NoCompression`, despite saying "no compression",
does *not* mean "store". It means "add the file 'normally', but tell
`DeflateStream` to use 'no compression'."
The result is that the zip entry doesn't say it's stored:
$ unzip -lv bin/Debug/*-Signed.apk | grep assemblies/
64512 Defl:N 64512 67% 06-16-16 10:38 6d65706b assemblies/Scratch.DebugRelease.dll
Which in turn means that the resulting `.apk` is *unusable*.
The fix? `System.IO.Compression` can't be used for this, and
`Ionic.Zip.dll` had other problems (why we tried to use
`System.IO.Compression` in the first place!), so instead we'll
use [libZip][0] and [LibZipSharp][1] to handle `.apk` files.
libzip is a well-maintained OSS library for manipulating zip files,
and LibZipSharp is a C# wrapper around libzip.
Add libzip and LibZipSharp to the build system so that they're
available on required paltforms, and update the `BuildApk` and
related tasks to use LibZipSharp instead of System.IO.Compression.
This allows assemblies to be properly stored in the `.apk`,
allowing apps to execute as intended.
$ unzip -lv bin/Debug/*-Signed.apk | grep assembl
64512 Stored 64512 0% 06-29-16 08:31 6d65706b assemblies/Scratch.DebugRelease.dll
[0]: http://www.nih.at/libzip/
[1]: https://github.com/grendello/LibZipSharp/
2016-06-29 15:33:38 +03:00
|
|
|
[submodule "external/libzip"]
|
|
|
|
|
path = external/libzip
|
|
|
|
|
url = https://github.com/nih-at/libzip.git
|
|
|
|
|
branch = master
|
|
|
|
|
[submodule "external/LibZipSharp"]
|
|
|
|
|
path = external/LibZipSharp
|
|
|
|
|
url = https://github.com/grendello/LibZipSharp.git
|
|
|
|
|
branch = master
|
