The VS 2017 batch files print message to stdout that mess up the
environment extraction. Try to silence them, and ignore whatever else
it decides to print unconditionally.

The curl that ships with the latest Windows 10 works fine, but people
often have bad curl installations which can make bootstrap fail.
Always Use urllib2 on Windows, and we should move to using it
exclusively on all platforms.

Already upstream at https://github.com/mesonbuild/meson/pull/3808

Also remove an unused patch that was accidentally committed.

Vincenzo Bono authored Jun 26, 2018 and Nirbheek Chauhan committed Jun 29, 2018

Added Platform.Linux in or to Platform.android, before the check for Architecture.ARMv7.

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

Turns out unknown files are *not* ignored anymore. Fixes packaging
failure when building cross-windows with MinGW.

With the Meson port, we can now build many recipes with MSVC, and we
will default to doing that on Windows. People can switch to MinGW-only
by adding 'novisualstudio' to variants in ~/.cerbero/cerbero.cbc

We always needed an MSVC compiler for building the directshow plugins,
and we need lib.exe from Visual Studio to generate import libraries
from DLLs for all recipes built with Autotools.

This change documents that correctly and bumps the requirement to
Visual Studio 2015, which is what we support in GStreamer. VS 2013 may
work, and support for it can be added if enough people ask for it.

Also fix the documentation about how to install Python 3. The default
installation path is in `C:\Program Files (x86)\Python36-32` which
breaks Autotools and other shell-based builds. Note that Meson does
not require this.

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

PDB files contain MSVC debug information, and are created by the MSVC
linker for EXEs and DLLs. Hence, we have PDBs from three categories:
plugins, libraries, and binaries.

This commit includes PDBs from all three sources into the -devel
package.

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

Atomic ops are always available with MSVC. This change is already
upstream.

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

This is necessary for GCC/LD to be able to import variables exported in
MSVC DLLs. We need this while building with Meson on Windows with MSVC.

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

Unless the 'visualstudio' variant is disabled in the config by enabling
the `novisualstudio` variant, recipes that use Meson will be built
using Visual Studio.

Cerbero will attempt to find either Visual Studio 2015 or Visual Studio
2017 and set the correct environment to use the MSVC toolchain. This
is done once at startup, and then used by each recipe at build time.

To get this environment in shell form, use the `win32-msvc-shell.cbc`
and `win64-msvc-shell.cbc` config files.

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

... when we do cross-win* bootstrap. It seems most of the
bootstrapper did not know about this.

It hangs randomly during configure, and makes unattended builds
annoying. This is the workaround that people have been doing manually
for years on Windows.

Eventually, we will get rid of this entirely once we move to Meson.

/mingw/ is not a known path for a non-MSYS Python, which we recommend
using.

We never want recipes to download wrap files automatically since we
provide all dependencies.

Needs extra quoting for extra config arguments passed to ffmpeg that
have spaces in them.

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

Use --disable-fatal-warnings instead.

Also, always disable gtk-doc. No one cares about it in Cerbero.

ssize_t is not available on MSVC, so you can't #include it from code
that will be built with MSVC.

check_call doesn't always inherit the current environment, so it would
run the wrong Perl because our PATH changes were ignored. However, this
only happened in a `package` run where some other recipe was built
beforehand.

Instead, use `which()` now so that we read PATH directly. Also don't use
environment variables to communicate the perl path, we already have that
information in self.config.

Earlier we were just eating the error, which is unexpected and useless
for the user.

Upstreamed, should be in the next release:
https://gitlab.gnome.org/GNOME/glib-networking/merge_requests/4

This actually causes the install_name to have the prefix twice:

/Library/Frameworks/GStreamer.framework/Versions/1.0//Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libopenjp2.7.dylib

Removing the patch turns it back to:

/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libopenjp2.7.dylib

Which is correct.

This is required for generating static libraries for Android and iOS

This was changed in Meson, but it's a bad idea because then we can't
find plugins built with Autotools.

Upstream bug: https://gitlab.gnome.org/GNOME/glib/issues/1413

Also remove a useless post_install from gstreamer-1.0.recipe with
the nice side-effect of rebuilding it which is needed for this to
work.

Upstream PR: https://github.com/mesonbuild/meson/pull/3691

With this, darwin_x86_64 builds successfully for me.

And fix build failure on non-mac platforms, where the suffix would be
set to '' instead of the default value for that platform.

Already fixed in master, this fixes compiler warnings about visibility
attributes in the headers.

This reverts commit 54f8773d.

gst-validate-runner.c: In function 'gst_validate_init_runner':
gst-validate-runner.c:840:1: error: visibility attribute not supported in this configuration; ignored [-Werror=attributes]
cc1: all warnings being treated as errors

This error is incomprehensible. There is no visibility attribute there.

ffmpeg 4.0 and above have the necessary bugfixes for it, but the
version we're using currently does not.

Add it only for ffmpeg because our own code must build while
targetting Vista and above.

intltool support was patched out in commit 1a456a9f, so this
should no longer be needed. Would fail like this on a
mingw cross-win64 build on debian 9.4:

[(36/44) libsoup -> configure ]
Running command 'gtkdocize && intltoolize --automake --copy && autoreconf --force --install --verbose'
/bin/sh: 1: intltoolize: not found
Recipe 'libsoup' failed at the build step 'configure'

Cerbero ignores changes to patches. Fixing this seems to be non-trivial.

Synced patch with upstream PR.

When added in init, they leak into the environment and cause build
failures because configure checks for other ios platforms fail.

Autotools only add LDFLAGS when doing compiler checks, so add
bitcode cflags to LDFLAGS too

Since 2015, this environment variable gets automatically unset in new
terminals because of new macOS security features.

This can be disabled by booting into recovery mode and running csrutil
to disable it. However, we want everyone to have the same environment,
including people who disable that and those that use older macOS
versions, so remove it entirely lest more build issues crop up.

The locale is badly defined in that case and "C" is used as the fallback
locale, which causes Python's open() to barf on utf-8

Requires this meson PR: https://github.com/mesonbuild/meson/pull/3609