GitLab

Fixes:

WARNING: Project targeting '>= 0.50.0' but tried to use feature introduced in '0.54.0': native arg in add_languages.
Part-of: <!47>

If nasm is used to build an 'empty' assembly file, it still outputs an
object file for it but the MSVC linker seems to hang when linking to
it. This only happens for the v360 filter because the assembly helpers
are wrapped inside `%if HAVE_AVX2_EXTERNAL`.

Remove that if to fix the hang, and also because the if is wrong. The
functions should always be compiled and they will be plugged in at
runtime if AVX2 is found. That's exactly what `ff_v360_init_x86()`
inside `vf_v360_init.c` already does.

Reproduced with:
Microsoft (R) Incremental Linker Version 14.26.28806.0
NASM version 2.14.02 compiled on Dec 26 2018
Microsoft (R) C/C++ Optimizing Compiler Version 19.26.28806 for x64

Part-of: <!46>

The static library we link against depends on symbols found in
the other link_withs. As meson passes --as-needed, we need to
ensure that the linker looks up all the undefined symbols in
the static library in the libraries that follow it on the command
line.

Part-of: <!44>

old gcc complains specifically when this pragma is used inside
a function.

Part-of: <!44>

Passing it in the default_options implies it may get overridden
or ignored, and we will fail to build. Instead simply add it
in the project arguments.

Part-of: <!44>

Making decklink build working.

Part-of: <!42>

And rename 'check_libs' to 'check_components' as they are not only used
for libraries.

Part-of: <!42>

Part-of: <!42>

Part-of: <!42>

Fixes #13

Part-of: <!42>

And write the meson.build files in place.

Update the meson files adding required information about generated parts

Part-of: <!42>

Part-of: <!41>

Part-of: <!40>

Fixes:
WARNING: Project targeting '>= 0.49.0' but tried to use feature introduced in '0.50.0': install arg in configure_file

Part-of: <!38>

When a check lists multiple libraries to link with, we need to
fail if any of them isn't available.

Part-of: <!39>

Don't need the rules: bit.

openh264 can be found internally and shoud not be enable in
FFMpeg. Use only external dependency.

Fixes "Dependencies must be external dependencies" meson error.

gstreamer/gst-build#87
!31

msys2 seems broken right now.

!11

rebuild of the image cause the previous one couldn't
run 32bit binaries due to a secutiry patch apprently

https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t

Only write out the list of muxers, demuxers, encoders, etc, if the
list has changed from last time. This avoids unnecessary rebuilds
because the file stat() would always change on reconfigure even though
the contents are the same.

This almost halves the amount of time needed by the CI, since the
MSYS2 job is the slowest and it blocks the x86 jobs from starting.

In case it ever fails, we should error immediately, not at some random
place later.

It was using set() for holding dependencies, which does not have
a guaranteed order. Because of this, the order of libraries in the
linker lines were changing randomly, causing all the exes (1000 of
them, including tests) to be rebuilt even for no-op builds on
reconfigure.

And the image being used.

Fixes #12

See #11

Currently the container is based upon a windows 1607 image
and requires a runner with a server/hyper-v 1607 host
to be able to execute.

There are plan on moving the runner to a 1807 later.

Otherwise we'll get cryptic Meson warnings such as:
" ERROR: <ExternalProgram 'python3' -> ['/usr/bin/python3']>
is not a valid python or it is missing setuptools"

We don't use an assembler for non-x86 builds

Matches the same option available with ./configure, except we disable
it by default to speed up gst-build builds.

Closes #7

They should always be libfoo.pc

Fixes #2