Age | Commit message (Collapse) | Author |
|
When doing a multi threaded build i come across the following
CMake Error at build/BundleFiles.cmake:1 (file):
file COPY cannot find
"/Users/brent/Dev/macos/build/addons/skin.estuary/media/Textures.xbt": No
such file or directory.
make[3]: *** [CMakeFiles/bundle_files] Error 1
make[2]: *** [CMakeFiles/bundle_files.dir/all] Error 2
The bundle_files target is being executed before several files are in place.
This affects both the pack-skins target and the libdvdnav target. Rather than add
both to the dependency list of bundle_files, have just added the main app target.
The idea is that the main app target, and all its dependencies (eg .so, skin packing)
are done, so the bundle copy commands can work without any hassle
|
|
|
|
|
|
|
|
[tools/depends] Bump python 3.11
|
|
|
|
|
|
|
|
Fix CMake warning in windows/ArchSetup.cmake
|
|
|
|
|
|
|
|
|
|
|
|
[jenkins] Build android as RelWithDebInfo by default
|
|
|
|
Spdlog vendor cmake target is spdlog::spdlog, so utilise that.
Fix windows building with wchar options when built internal.
|
|
This function allows us to handle in a generic way our use of internal lib state,
and to then allow it to be overridden more easily by the user.
cmake_dependent_option has proven too restrictive for our use of it.
|
|
spdlog/fmt
If a dependency lib is rebuilt, allow a way to notify the calling parent that the dependency
is being built. This then allows the parent to rebuild to make sure all the correct
versions of a lib are inline.
Eg Spdlog exists and was built against FMT 7.0.1 (we cant know what version). We no longer
have FMT lib, so it is rebuilt (ver 8.0.1). Allow spdlog to recognise that its dependency
is being force built, and therefore it should rebuild to make sure the same lib/api is
used throughout.
|
|
The use of this is to allow a find module to get a version of a dependency
from a VERSION file without smashing the find module SETUP_BUILD_VARS variables to
allow us to provide a version to a find_package call of the dependency
|
|
|
|
|
|
[cmake] link atomic library for certain CPU architectures
|
|
Closes #21771
|
|
|
|
Allows a user to pass through cmake arguments to all addon dependencies that are built
Be aware, this is a global addition, and will be passed through to all addons built.
Usage:
-DADDON_EXTRA_ARGS="-Ddefine1=1 -Ddefine2=2"
The arguments will be passed through as a list (ie -Ddefine1=1;-Ddefine2=2) to all
addon dependencies built, and will be accessible via their CMakelists.txt files
an example is with visualization.projectm. If a user wishes to set -DAPP_RENDER_SYSTEM=gles
for the projectm dependency to build projectm as gles compatible.
Currently this can be done with a toolchain file, but a user cant set -DAPP_RENDER_SYSTEM=gles
as art of their cmake stanza to build the addon, as dependencies are passed through filtered
lists, of which APP_RENDER_SYSTEM isnt specifically passed through.
https://github.com/xbmc/visualization.projectm/issues/87
This solution provides a more generic way to pass through arguments to cmake dependencies
without us explicitly handling each option in HandleDepends.cmake
|
|
For those CPU architectures:
RISC-V lack 8-bit and 16-bit atomic instructions, and
ARM/MIPS/PPC lack 64-bit atomic instruction.
GCC is supposed to convert these atomics via masking and shifting
like LLVM, which means anything that wants to use these instructions
needs the link option -latomic.
In this patch, we will try to detect if 8-bit, 64-bit atomic instructions exist,
otherwise the atomic library will append to the DEPLIBS list.
Original issue:
* https://gitlab.kitware.com/cmake/cmake/-/issues/23021#note_1098733
For reference:
* https://gcc.gnu.org/wiki/Atomic/GCCMM
riscv64 specific:
* https://lists.debian.org/debian-riscv/2022/01/msg00009.html
Signed-off-by: Yixun Lan <dlan@gentoo.org>
|
|
Allows us to append arch specific flags to platform generic deps
eg, allow flags-arm64.txt and flags-x86_64.txt to append to extraflags
passed to a cmake based dep only when the specific arch type of the platform is built
Many platforms have the ability for multiple arch (osx x86_64/arm64, android armv7/aarch64, etc)
So this allows us to provide targeted arch specific flags where appropriate
This APPENDS to any flags found in flags.txt of a dep. flags.txt continues to hold any flags
that are common across all platform arch types.
|
|
|
|
The local tarballs specified via custom MODULE_URL can be different
from what is pinned in 'tools/depends/target/*/*-VERSION' files.
This manifested during preparation of 20.0 Alpha 2 build in Debian
where libdvd* tarballs are custom.
Now specifying MODULE_HASH along with MODULE_URL works as expected.
Signed-off-by: Vasyl Gello <vasek.gello@gmail.com>
|
|
|
|
[cmake] Allow specifying HOST_CAN_EXECUTE_TARGET
|
|
Executing the target binary will not work when cross-compiling to a
uClibc-based target on a glibc-based host.
https://github.com/xbmc/xbmc/commit/b9a0c7b1f402613e96876ccfec316831801352bd
broke cross-compiling in this case:
-- Found Python3: /home/buildroot/buildroot/output/per-package/kodi/host/x86_64-buildroot-linux-uclibc/sysroot/usr/include/python3.10
(found suitable exact version "3.10.5") found components: Development Development.Module Development.Embed
-- Could NOT find Python3 (missing: Interpreter) (Required is exact version "3.10")
Reason given by package:
Interpreter: Cannot run the interpreter
"/home/buildroot/buildroot/output/per-package/kodi/host/x86_64-buildroot-linux-uclibc/sysroot/usr/bin/python3.10"
$ file /home/buildroot/buildroot/output/per-package/kodi/host/x86_64-buildroot-linux-uclibc/sysroot/usr/bin/python3.10
/home/buildroot/buildroot/output/per-package/kodi/host/x86_64-buildroot-linux-uclibc/sysroot/usr/bin/python3.10:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64-uClibc.so.0, not stripped
This patch allows to force -DHOST_CAN_EXECUTE_TARGET=FALSE to avoid
executing the target version of python3 although the host version was set
in configure options:
-DPYTHON_EXECUTABLE=/home/buildroot/buildroot/output/per-package/kodi/host/bin/python3.10
$ file /home/buildroot/buildroot/output/per-package/kodi/host/bin/python3.10
/home/buildroot/buildroot/output/per-package/kodi/host/bin/python3.10:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=0502eef4c126feb4162aea6d36f321387f2a58fc, for GNU/Linux 3.2.0, with debug_info, not stripped
|
|
|
|
|
|
|
|
[cmake] FindNFS module to build internal
|
|
[cmake] Build LibZip during cmake Build
|
|
|
|
|
|
|
|
EFFECTIVE_PLATFORM_NAME platform functions with current tools/depends cmake
version 3.21.3. The workaround actually causes cmake targets to be incorrectly applied
and generated, so remove.
|
|
libzip is only used by android.
It supports cmake build system, so lets just build during core cmake build in Find modules
rename folder to libzip to match libname
|
|
|
|
|
|
calls
|
|
|
|
|
|
|
|
libdvd doesnt use SETUP_BUILD_VARS macro, so some variables arent set.
Manually set the required vars.
|