Upstream source is https://github.com/scikit-build/cmake-FindVcvars
BSD-3 licensed. We use as is. There was an effort for the creators to upstream into
cmake itself, but so far hasnt materialised. For now, add in tree.
CONFIGURE_COMMAND and BUILD_COMMAND are separate environments, so set DEP_BUILDENV
to populate tools/info to the build step as well as the configure step
TexturePacker is being installed twice, but this is only noticeable when
installing Kodi with DESTDIR, which is common in distributions. The copy
installed by FindTexturePacker.cmake normally gets reinstalled in place,
but with DESTDIR applied, it lands under /path/to/destdir/path/to/build.
There is no need for FindTexturePacker.cmake to install it anyway. This
change stubs the install command, runs TexturePacker from its build
location, and the wider Kodi installation sources it from there.
Jenkins default for make-mingwlibs build step was
%WORKSPACE%\tools\buildsteps\windows\x64\make-mingwlibs.bat noprompt noclean sh
Update BUILDMODE to noclean to continue with that behaviour
Do single pkg search using pkgconfig to initially populate _FOUND variables for
ffmpeg components. This allows us to enforce tools/depends/target/ffmpeg versioning
to correctly rebuild internal ffmpeg for tools/depends platforms whilst still respecting
API compat minimum versioning
FFMPEG may sometimes be API compatible across major versions, although this is not
guaranteed. For tools/depends platforms and windows, track the version number of
tools/depends/target/ffmpeg versions, but also keep the minimum compat versions
for other platforms that may provide system libs
Tahoe seems to be setting *_DEPLOYMENT_TARGET variables for targets that arent
required for a project. Force unset the unnecessary variables to stop issues with
targets that shell out their process, which would inadvertently then think it was
building an incorrect target
example error
/macos/clang:1:1: conflicting deployment targets, both '12.0' and '25.1' are present in environment
example env
<...>
DRIVERKIT_DEPLOYMENT_TARGET = 25.1
<...>
IPHONEOS_DEPLOYMENT_TARGET = 12.0
<...>
XROS_DEPLOYMENT_TARGET = 26.1
<...>
generate a cross file named after find module library. This allows us to have
custom meson cross per target to allow customisations on required info to pass to meson
build of a target.
The second search name causes the expected variables to not be set. Bluez is considered
the defacto for unix, so just drop back to a single search for it.
Some systems have case sensitive FS, FlatBuffersConfig.cmake was not being found
with the search name of flatbuffers. Add NAMES alternatives that respect case