Since we store local sources inside the cerbero home dir (build/),
we download multiple copies of the sources for each cerbero clone or
if the user deletes the homedir or moves the git repository.

We still keep the old value for non-default cases where the user has
a configuration that overrides the default value of home_dir.

https://bugzilla.gnome.org/show_bug.cgi?id=797323

Justin Kim authored Oct 17, 2018 and Sebastian Dröge committed Oct 27, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=797296

Justin Kim authored Oct 24, 2018 and Sebastian Dröge committed Oct 27, 2018

https://bugzilla.gnome.org/show_bug.cgi?id=797331

GNOME, GNU, Savannah, Xiph, and SourceForge source URLs now use
templates. More templates can be added in the future. Currently, they
can be one of the following forms:

  scheme://

This will download a file called %(name)s-%(version)s.tar.xz from the
canonical place on the specified server. `scheme` can be: gnome, sf,
gnu, savannah.

  scheme://.tar.gz

For using the template but with the specified file extension instead
of .tar.xz

  scheme://some/path/to/name-version.tar.xz

For using the template only for the mirror domain and common sources
path.

https://bugzilla.gnome.org/show_bug.cgi?id=797330

For use in URLs that use the first two version components in the URL.

https://bugzilla.gnome.org/show_bug.cgi?id=797330

This wasn't enabled with autotools, and it shouldn't be with meson.

Meson requires 64-bit ARM to be defined as 'aarch64', not 'arm64',
and the cpu_family for all ARM variants is 'arm'.

https://mesonbuild.com/Reference-tables.html#cpu-families

Earlier, we were assuming a specific obsolete layout of Visual Studio
for finding the standalone VC tools prefix. These VC tools are no
longer installed by default.

lib.exe is always available inside the Visual Studio prefix that we
use for building many of the Meson recipes, so use that instead.

Instead of computing the vcvarsall at the module level, add a function
for it and use that. This also allows us to target a specific version
of Visual Studio (2015/2017/etc).

Fixes all CI:

TypeError: stat: can't specify None for path argument

When we cook the build-tools recipe, we temporarily override the
current environment with one derived from the build-tools
configuration, cook, and then re-set back to the old env.

We stopped doing this correctly after splitting out the 'fetch' step.
This caused a bootstrap failure because part of our build step was
using the wrong configuration.

The instruction given is no longer valid. `-c config/foo bootstrap`
is a superset of `bootstrap` now.

Also, this error gets hit when we run `fetch-bootstrap` for the first
time.

Fix a years-old bug in Python's zipfile module:
https://bugs.python.org/issue15795

Without this, the extracted Android NDK does not have executable
permissions on any binaries and is unusable.

https://bugzilla.gnome.org/show_bug.cgi?id=797316

We don't use this for downloading, and we don't want any recipes or
build systems to shell out to this and download anything from the
network. Everything needed for building must be downloaded in the
fetch stage.

https://bugzilla.gnome.org/show_bug.cgi?id=797316

This fetches all network resources required for running bootstrap,
including build-tools recipe sources, toolchain binaries, etc.

https://bugzilla.gnome.org/show_bug.cgi?id=797316

Now when you run bootstrap --offline, the bootstrappers will
not require network access.

All URLs downloaded in the fetch() step now point to locations with
fixed contents and are checksummed.

FIXME: On Windows mingw-get is still run which uses the network

https://bugzilla.gnome.org/show_bug.cgi?id=797316

This separates each bootstrapper into three distinct stages:

1. Fetch network resources into self.config.local_sources
2. Extract/copy network resources into the correct location
3. Run arbitrary commands that do not need network access

https://bugzilla.gnome.org/show_bug.cgi?id=797316

It hasn't been hooked up everywhere yet, the next commits will do that

https://bugzilla.gnome.org/show_bug.cgi?id=797316

We will reuse this base class for download tarballs during bootstrap.

https://bugzilla.gnome.org/show_bug.cgi?id=797316

Nothing uses it, and we're moving towards using only urllib2 for
downloads, which doesn't support recursive downloads.

https://people.xiph.org/~jm/opus/opus-1.3/

This is due to dllimport, which requires you to rebuild your object
files for shared and static with and without __declspec(dllexport).
This is necessary for MSVC support, and so ffmpeg requires it.

gdk-pixbuf can't be used with MSVC till all the image loaders have
been ported over too, otherwise it just crashes.

Otherwise on Windows we will build with the import libraries and try
to run with the DLLs in the build-tools bindir, such as libintl-8.dll

Fixes an ffmpeg build failure:

/bin/sh: arm-apple-darwin10-strip: command not found

Fixes out of date glib tools throwing errors.

/usr/bin/glib-genmarshal --prefix _gdk_pixbuf_marshal --output gdk-pixbuf/gdk-pixbuf-marshal.h --pragma-once --header ../gdk-pixbuf/gdk-pixbuf-marshal.list
FAILED: gdk-pixbuf/gdk-pixbuf-marshal.h
/usr/bin/glib-genmarshal --prefix _gdk_pixbuf_marshal --output gdk-pixbuf/gdk-pixbuf-marshal.h --pragma-once --header ../gdk-pixbuf/gdk-pixbuf-marshal.list

(process:12337): GLib-Genmarshal-WARNING **: failed to open "--output": No such file or directory

(process:12337): GLib-Genmarshal-WARNING **: failed to open "gdk-pixbuf/gdk-pixbuf-marshal.h": No such file or directory

(process:12337): GLib-Genmarshal-WARNING **: failed to open "--pragma-once": No such file or directory

...

The net/route.h header was removed from the iOS SDK for some reason and
its definitions are required to build libusrsctp.  Copy net/route.h from
the MacOS SDK as a workaround.

Since Python 3.3, the tarfile module also supports lzma compression
and the implementation is less buggy than the MSYS tar:

1. It does not error out on uids that are out of range
2. Handles symlinks correctly by coping the file on extract
3. Better error reporting

/ is evaluated before + which cause an error saying you can't
concatenate str to WindowsPath

Also add upstream PR links to the recipe.

This allows easy measurement of the time taken by each recipe and the
total time spent by Cerbero. The format is:

[HH:MM:SS] [(1/N) recipe_name -> fetch ]

https://bugzilla.gnome.org/show_bug.cgi?id=797288

We can't link to a static ffmpeg built with MinGW when gst-libav is
built with MSVC. Another big advantage of this is that people can
switch out the ffmpeg libs with their own DLLs, dylibs, etc when using
our binary builds without having to build from scratch with Cerbero.

https://bugzilla.gnome.org/show_bug.cgi?id=797287

In file included from ../src/graphene-alloc.c:24:0:
../src/graphene-private.h:28:5: error: "HAVE_INIT_ONCE" is not defined [-Werror=undef]