GitLab

Edward Hervey authored Nov 08, 2018 and Edward Hervey committed Nov 08, 2018

yum is the default on fedora >= 23

We weren't using the existing local sources at all when using
subversion; instead we were always deleting it and fetching
it from scratch.

These were getting pulled by recipes directly, which is incorrect and
unnecessary. Just add them to build tools instead.

The meson.py is meson-script.py, but we have meson.exe now so we don't
need to use the script at all.

Lib as libdir interferes with packaging.

Otherwise cerbero just throws an exception, and the only way to
recover is to wipe the build cache file and re-start from scratch.

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