Change vlc_modules_list format from just plugin names to name:path pairs.
This allows plugins built in SUBDIRS (like the Qt plugin) to specify
their actual location, enabling copy_plugins.sh to find them.
New format: plugin_name: relative/path/to/plugin.dylib
The path is relative to the top build directory as it also inject
$(subdir) in the path from Makefile.am.
This uses Xcode 26 along with its SDK for tvOS, macOS-arm64, watchOS,
iOS, iOS-Simulator-x86_64 and xrOS.
The macOS-x86_64 remains on the current runner.
It should build the QSV/MFX/VPL plugin by default.
The image also contains unzip and other updates to the unstable Debian.
The image also has
- a Rust stable toolchain in addition of the nightly one.
- FFmpeg 8
- libpostproc is gone (not built with FFmpeg 8)
- Qt 6.9.2 (from 6.7.2)
Allow users to specify a custom build configuration file using the
--config=FILE command-line argument. This enables build customization
without modifying the default build.conf, in particular to target
higher version of the platform or enable more modules.
Usage:
../extras/package/apple/build.sh \
--sdk=iphoneos --arch=arm64 \
--config=/path/to/custom.conf
Instead of expanding VLC_DEPLOYMENT_TARGET_CFLAG and
VLC_DEPLOYMENT_TARGET_LDFLAG to literal strings at generation time,
write them as make variable references in config.mak. This allows the
flags to be resolved at make time, allowing to modify them easily.
The variables for compiler flags are using direct assignment (ie. :=)
and the variables are interpolated directly. By moving the
VLC_DEPLOYMENT_TARGET up, we can use this variable in the compiler flags
instead of hardcoding it.
Note that the target cflag and target ldflag are still using hardcoded
values, because they are also used in VLC's configure.
The CDDB databse from freedb.videolan.org doesn't reply anymore (due to
MusicBrainz ?). freedb.org is dead and gnudb.org is empty.
CDDB was a fallback in case the MusicBrainz query didn't find any match but
we're just waiting time doing a query that will never provide any good answer
anymore.
In the some runners (builder-release.videolan.org, a Videolabs one) we can't run
commands in the git repository:
fatal: detected dubious ownership in repository at '/builds/videolan/vlc'
To add an exception for this directory, call:
git config --global --add safe.directory /builds/videolan/vlc
cat: /builds/videolan/vlc/extras/package/win32/../../../src/revision.txt: No such file or directory
See https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3538
When the user has CMake 4.x we should not build CMake 3.x
because we require at least 3.21.0.
This matching major version was introduced for protoc in ee5fad6a35. But
it has moved to contribs and other tools (not matching a library)
should be backward compatible.
If there is another tool that needs to match the major version exactly,
we should at a special check for that.
`snapcraft login --with` and `snapcraft push` are deprecated
```
$ echo $SNAP_LOGIN | base64 --decode | snapcraft login --with -
--with is no longer supported, export the auth to the environment variable 'SNAPCRAFT_STORE_CREDENTIALS' instead
Login successful
$ snapcraft push nightlies/vlc_*.snap --release edge
The 'push' command was renamed to 'upload'. Use 'upload' instead. The old name will be removed in a future release.
Credentials are no longer valid for the Snap Store.
```
when using SNAPCRAFT_STORE_CREDENTIALS environment variable, login and logout
aren't necessary
The snap package also builds the missing contribs.
They are currently the same between the debian-contrib and the snap job,
except the snap job also builds live555.
Even when linking we should use the -m<os>-version-min argument and
let the compiler set the proper low-level linker arguments instead of
second-guessing it, and getting it wrong in cases like when building for
aarch64 targeting 10.11, which never existed. Letting the compiler
handle this will result in the proper outcome:
ld [...] -arch arm64 -platform_version macos 11.0.0 26.1