It's expected to be in extras/tools

Tested cross compiling for armv7 with this docker image
registry.videolan.org/vlc-debian-raspbian:20200213203125

The contrib path is automatically added for contribs and for vlc.

We still need a proper environment to build VLC. We set the same values used in
contribs. They should always match. It could be removed once it's move into
configure.ac.

It uses the same detection for bogus Debian $TRIPLET-pkg-config.

Honor VLC_PREBUILT_CONTRIBS_URL env variable and produce packaged
tarball if prebuilt contrib is not available.

If the configure.ac changes, autotools will notice and rerun the necessary
commands to build properly. Same thing if a Makefile.am is modified.

If one of the local .m4 file is modified, it won't pick the difference. The
user will need to run the bootstrap manually (or remove the configure file).

Since ea96271f, contribs builds
dav1d 0.6.0, which requires nasm 2.14. (The version that extras/tools
is installing is already at 2.14, but the bootstrap script only
installed it if the existing one was older than 2.13.2 or missing.)

By default it will be $(TOPSRC)/../extras/tools/build which is not correct when
building out of tree for Windows. Because when building for Windows there's a
possibility the same source tree is built from within msys2 or WSL. They can't
share the tools.

Alexandre Janniaux authored 5 years ago and Marvin Scholz committed 5 years ago

Signed-off-by: Marvin Scholz <epirat07@gmail.com>

From https://github.com/mesonbuild/meson/pull/5912

This solves the -lpthread detection issue with libplacebo when compiling with
LLVM for Windows.

No need to add a lot of packages just to run one program.

Currently, lack of python3 is only detected very late in the build
process. To help developers, bail out early if its not there.

The itemArray property is settable in 10.14 and above only, so this commit adds a work-around to retain support with previous releases of macOS.

Versions above 0.51.1 don't add the -lpthread properly in libplacebo.pc.

This way, you can reveal the data about an individual item stored in the data base. The representation will be moved to a different place, so this is notably for debug purposes for now.

It's still not in 3.16.2 or 3.16.3...

This version contains Hugo's patch to properly cross compile under Linux:
FindPkgConfig: Fix path manipulations when cross compiling

When cross compiling from a unix machine, if(UNIX) is false,
which causes the path not to be fixed for unix, leading to false
negative if PKG_CONFIG_PATH needs to be probed

Updating my Debian went from 3.13.4 to 3.15.4 which breaks PKG_CONFIG_PATH
usage.

This platform was used by iPhone 5 only, which can also execute ARMv7 and is quite dated now, so the maintenance burden cannot no longer be justified.

This way, they are no longer burried in a build folder where no-one can find them.

The CFLAGS were not honored so the module list was always compiled for
the native compiler. When later combining the objects with libtool,
it would create a FAT binary with a x86_64 part containing just the
module list and an ARM part containing everything else.

This adds a separate target to add an SDK version of the macOS
binaries. This package is the result of a destroot'ed 'make install'

It shall serve two purposes:

1) Out of tree modules compilation: Module authors can use the included
pkgconfig files to link against libvlc(core) for their own modules.
This is similar to the existing SDK we have on Windows.

2) Packaging libvlc for our own app: If someone does not want to use
VLCKit, but links against libvlc directly, these precompiled artefacts
can be used for packaging the libs into the own app. Packaging shall
be done in the same way as with VLC.app (i.e.: lib/* and the vlc plugins
directory goes to Contents/Frameworks, share/ goes to
Contents/Resources/share/ if needed). In this case, all ressources are
found by libvlc automatically.

Users can also execute vlc directly from the extracted tarball, after
specifying LD_LIBRARY_PATH and VLC_PLUGIN_PATH. Using the macOS UI
module is not supported.

This gets rid of a prefix inside our build dir, and uses DESTDIR
when installing the content. This way, the install directory
can be reused for further packaging introduced in the next commits.

This fixes the workaround for cross-compilation for the iOS Simulator
introduced in 43826f9f