GitLab

Applying upstream PR to fix missing large file support on Windows MinGW build

Part-of: <gstreamer/cerbero!498>

Perl's version number in the `--version` looks like: `(v5.30.2)`.
However, other tools like cmake look like: `'cmake version 3.17.3'`.

Need to change the regex. This broke in the previous commit
f12e5ed2

Part-of: <gstreamer/cerbero!499>

cmake and nasm needs minimum version.
Add a test to build it if needed.

Part-of: <gstreamer/cerbero!483>

Sometimes we install things into lib/gstreamer-1.0/include, so remove
those too when disabling a library.

Part-of: <gstreamer/cerbero!497>

Really silly oversight.

Part-of: <gstreamer/cerbero!497>

Part-of: <gstreamer/cerbero!497>

Enable dash plugin explicitly, and add the dependency that it was
missing. Also enable ladspa plugin explicitly, which was missed while
adding it.

Part-of: <gstreamer/cerbero!497>

It was never shipped with our binaries. We were building it and
throwing it away.

Part-of: <gstreamer/cerbero!497>

The CRT interop issues have been resolved ever since we updated the
toolchain.

Part-of: <gstreamer/cerbero!497>

Part-of: <gstreamer/cerbero!497>

libxml2 is not actually used, and the opengl plugin is built on all
platforms so there's no need to make platform-specific files
properties for it.

Part-of: <gstreamer/cerbero!497>

We use it but don't import it.

Part-of: <gstreamer/cerbero!497>

Upstreaming these is going to be a long-ish road, so put the patches
in a subdir so it doesn't bother people.

Part-of: <gstreamer/cerbero!497>

Part-of: <gstreamer/cerbero!494>

Part-of: <gstreamer/cerbero!494>

Part-of: <gstreamer/cerbero!495>

Part-of: <gstreamer/cerbero!493>

Part-of: <!492>

Part-of: <gstreamer/cerbero!492>

Part-of: <gstreamer/cerbero!491>

Future tarballs will be gst-editing-services-1.x.y.tar.xz,
so we can drop the special-casing here.

Part-of: <gstreamer/cerbero!490>

There will be gst-devtools tarballs in future as well, so
we can make this into a 'normal' gstreamer module now and
remove the special-casing.

Part-of: <!490>

These haven't been used ever since glib was ported to Meson:

glib_cv_stack_grows is now set as a cross property
glib_cv_uscore is correctly detected with meson
getpwuid_r is correctly detected with meson
getgrgid_r is correctly detected with meson
wchar_t is available and things work fine (added in 2013, no notes)
_NSGetEnviron is fixed in the previous commit

Part-of: <gstreamer/cerbero!489>

Sync the host_system == ios change with upstream, and don't look for
`_NSGetEnviron()` on iOS. This regressed when moving to Meson since it
was set via `ac_cv_func__NSGetEnviron` in `ios.config` and was missed.

Part-of: <gstreamer/cerbero!489>

Part-of: <gstreamer/cerbero!489>

`.` at the end of cmake command is not necessary because the build and
work directory are explicitly specified with -H and -B options. In
cmake version 3.10.2 and older cmake 3 version  dot at the end leads
to ovewriting the value of -H option.

Part-of: <gstreamer/cerbero!484>

Needed for Windows arm64 support.

Part-of: <!480>

Make this a strict opt-in so we can track the usage of this feature,
and to minimize the risk of bugs.

Part-of: <!480>

Adding a leading space to any env var with a path in it will cause
MSYS to interpret it as an MSYS path and convert, f.ex.
C:/foo/bar to C;C:\\MinGW\\msys\\1.0\foo\bar

In our case, this causes a build failure in openssl.

See also: fbaf3bc4

Part-of: <gstreamer/cerbero!480>

These should be set after we've added the toolchain flags from the
platform config. Otherwise they will get unset when we call
`set_env()` in `setup_toolchain_env_ops()`.

Part-of: <gstreamer/cerbero!480>

Otherwise LDFLAGS is incorrect.

Part-of: <gstreamer/cerbero!480>

Part-of: <gstreamer/cerbero!480>

Otherwise none of the toolchain build tools will actually be found.
Only the ones provided by MSYS will be found.

Part-of: <gstreamer/cerbero!480>

Part-of: <gstreamer/cerbero!480>

Since Visual Studio is optional now, this patch is non-trivial.

Part-of: <gstreamer/cerbero!480>

Unlike any other platform, on Windows we build recipes with both
MSVC and MinGW. All Meson recipes can be built with MSVC, but the
Autotools recipes always use MinGW.

This broke the fundamental assumption that `self.config.config_env`
contains all the information needed by the build system to find the
toolchain that we want to use.

At the time, we hacked around it by unsetting MinGW toolchain env vars
inside `build.py`, and storing msvc toolchain env vars in
`self.config.msvc_toolchain_env`. We would then set those only when
building recipes that can use MSVC.

This completely breaks down when you want to cross-compile on Windows,
because we need some env vars to stay in the env, and others to only
be in the cross file.

To fix this, a bunch of things had to change:
1. Use actual objects for environment variable values: `EnvValue` and
   other classes that inherit from it. These allow easier
   merging/overriding of env var values.
2. Separate out env vars according to their stated purpose:
   a) Configuration for build tools (WINEPREFIX, WINDEBUG, etc)
   b) Configuration for toolchain (LIBRARY_PATH, INCLUDE, LIB, etc)
   c) Configuration for build system (CC, CFLAGS, ac_cv_*, etc)
3. Always use a native-file or a cross-file for selecting the
   toolchain when using Meson.
4. Rename meson_cross_properties to meson_properties, since we use
   those even when not cross-compiling.

Future TODO: port all env var usage in config.py and config/*.config
to the new EnvValue* objects

Part-of: <gstreamer/cerbero!480>

We will use this for the windows.config rewrite later.

Part-of: <gstreamer/cerbero!480>

Part-of: <gstreamer/cerbero!480>

When a build fails and we enter the shell, we should use the env that
the recipe is using, not the env that is set globally on the config.

Part-of: <gstreamer/cerbero!480>