When building utfcpp (and other packages) a CMake warning is issued.
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_EXPORT_COMPILE_COMMANDS
Before this change the following files are present:
$ cd build.LibreELEC-Generic.x86_64-13.0-devel/build
$ find utfcpp-4.0.6 -name build.ninja
utfcpp-4.0.6/.x86_64-libreelec-linux-gnu/build.ninja
$ find utfcpp-4.0.6 -name compile_commands.json
$ find soxr-0.1.3 -name build.ninja
soxr-0.1.3/.x86_64-libreelec-linux-gnu/build.ninja
$ find soxr-0.1.3 -name compile_commands.json
soxr-0.1.3/.x86_64-libreelec-linux-gnu/compile_commands.json
When removing the define CMAKE_EXPORT_COMPILE_COMMANDS:
--- a/scripts/build
+++ b/scripts/build
@@ -147,8 +147,7 @@
MESON_BUILD_TYPE="plain"
fi
-CMAKE_GENERATOR_NINJA="-GNinja \
- -DCMAKE_EXPORT_COMPILE_COMMANDS=ON"
+CMAKE_GENERATOR_NINJA="-GNinja"
# configure TARGET build defaults
TARGET_CONFIGURE_OPTS="--host=${TARGET_NAME} \
The resulting build do not have the warning with utfcpp but the files
compile_commands.json are not created (as expected.)
$ find utfcpp-4.0.6 -name build.ninja
utfcpp-4.0.6/.x86_64-libreelec-linux-gnu/build.ninja
$ find utfcpp-4.0.6 -name compile_commands.json
$ find soxr-0.1.3 -name build.ninja
soxr-0.1.3/.x86_64-libreelec-linux-gnu/build.ninja
$ find soxr-0.1.3 -name compile_commands.json
With the change to declare CMAKE_EXPORT_COMPILE_COMMANDS as an environment
variable the warning is not preset with utfcpp and the compile_commands.json
are created, matching the current functionaility but without the warning.
Ref:
- https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html
- This is initialized by the CMAKE_EXPORT_COMPILE_COMMANDS environment variable.
- https://cmake.org/cmake/help/latest/envvar/CMAKE_EXPORT_COMPILE_COMMANDS.html#envvar:CMAKE_EXPORT_COMPILE_COMMANDS
- https://stackoverflow.com/questions/20059670/how-to-use-cmake-export-compile-commands
Allows packages to be updated to remove the configure warning:
configure: WARNING: unrecognized options: --disable-static, --enable-shared
add the following line to the affected package.mk files
PKG_BUILD_FLAGS="-cfg-libs"
-cfg-libs, -cfg-libs:host and -cfg-libs:init are used
Package building honor's the strip flag so we can prevent executables
from being stripped.
But copying files to INSTALL ignored that flag which meant the flag
had practically no effect.
Fix this by using the same logic as we do in the meson strip handling in
line 170 and in config/functions.
Also add the missing quotes in scripts/build to align it with config/functions
Signed-off-by: Matthias Reichl <hias@horus.com>
Several packages and buildsystems (most notably cmake) badly trip
over CC="ccache gcc" so create local wrapper scripts in the build
dir and set CC/CXX to them to work around that - like we do for
host-gcc and gcc in toolchain.
Signed-off-by: Matthias Reichl <hias@horus.com>
fixup scripts/build local-cc wrapper
Timing detail reporting can be enabled by setting
TRACE_BUILD_TIMING=1
This enables timestamping collecting at various build stages so we
can easily analyze how long eg configure, make/build, install etc
steps take.
Signed-off-by: Matthias Reichl <hias@horus.com>
Using -DCMAKE_BUILD_TYPE=MinSizeRel result in finally building with -Os. Our default
optimization or '+speed' are ignored, behavior is like always using '+size'.
Changing to default -DCMAKE_BUILD_TYPE="" is not allowed by to many packages including
Kodi, they are forcing a default option (in worst case "Debug", e.g. llvm)
Redefine the cmake parameters to not include any options and do the same for host choosing
"Release" as build type.
commit c468820ba9 "scripts/build: cleanup"
started to silently remove *.o files from the installation without
giving an explanation why this should be needed.
Drop that as it prevents packages from including *.o files in the
image, which eg is needed to include IR BPF decoders in LibreELEC.
Packages which install *.o files that should not end up in the image
should manually remove these in post_makeinstall_target.
Signed-off-by: Matthias Reichl <hias@horus.com>
