Specifying only a branch like '2019-08' is problematic if upstream commits
something between the builds of two containers.
We could make a tarball in the first container build and reuse that, but we
need the flexibility of Git for some patching in the Android and JavaScript
builds, so instead we allow specifying a git tree-ish as the third argument.
We can therefore also give a pretty version string to use for the image name
as second argument, e.g. 6.6.0.160 for bef1e6335812d32f8eab648c0228fc624b9f8357.
As we can't `git clone` a commit hash directly, we still need to provide both
branch name and then commit hash for this use case.
To get WebAssembly templates to actually work, we need to use
Mono 6.6 (currently in preview), which doesn't have tags yet
but is in the `2019-08` branch. So I dehardcoded the `mono-`
prefix for the git tree-ish to allow using `./build.sh 2019-08`.
6.6 doesn't build with msbuild 16.0, so I'm upgrading to its
matching version 16.3. There are no DEB files for 16.3 on the
EOL'ed Ubuntu 14.04, but it seems that the 16.04 packages install
cleanly.
We also backport a patch from mono's master branch to fix wasm
support further, and enable parallel build jobs for make.
The previous `['/bin/bash']` was not working, running the image
with `podman run -it <name>` would evaluate to:
```
> sh -c ['/bin/bash']
sh: [/bin/bash]: No such file or directory
```
The main reason is that upstream Mono tends to miss some
important files in its tarballs, so Git tags appears to be
a more reliable medium.
Also group RUN commands to reduce the number of intermediate
dependencies.
This saves us from pulling gtk2 and gtk3 as weak deps of
perl and git or whatnot... And we don't need to pull in all
the documentation on Ubuntu.
Also ensures that we properly run `dnf clean all` after each
installation.
Install xz/xz-utils and conditionally handle tar.xz tarballs from 6.0+.
On Windows, I ran into a build issue due to `make distclean` being
bogus in 6.0.0.319 (mono/mono#16605), so I worked it around by starting
from a clean folder for each build.
The hotfixed mingw-binutils packages should likely be rebuilt against
Fedora 30's mingw-binutils, but I didn't find the src.rpm in the repo
to do it. There were no functional changes between F29 and F30's
mingw-binutils though, so we should be fine as is:
https://src.fedoraproject.org/rpms/mingw-binutils/commits/f30
The `MONO32_PREFIX` and `MONO64_PREFIX` are no longer used by the
buildsystem (replaced by a `mono_prefix` build option), but I kept them
where relevant to point to non-standard install locations.
* Mono config on MacOSX is not portable from the Linux and Windows
version.
* Rename the compilers so that 'gcc' and 'g++' are the new version by
default.
* Add default environment variables to containers.