They're used by QtBuildInternals to find other components configuration.
With QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR set, cmake will only look
into those directories.
$make_check_pre can be used for wrapper commands like xvfb-run or
dbus-run-session which are common ways to make tests work. This way many
templates can avoid defining their own do_check function.
Normally, we can add them into configure_args directly.
However, if we need to link with 2 or more libaries (e.g. -latomic
and -lexecinfo on armv6-musl), we have noway to do it properly:
- configure_args will be splited on whitespace
- cmake denies to recognise CMAKE_*_STANDARD_LIBRARIES as a list,
hence denies to split on semicolon (";")
Let's pass LIBS as CMAKE_*_STANDARD_LIBRARIES instead.
- CMAKE_BUILD_TYPE=Release will force -O3 instead of respecting our
CFLAGS and CXXFLAGS
- Theoretically, we could patch cmake to always use -O2 instead,
however, patching will break users' expectation when compiling their
our code.
- RelWithDebInfo could be another option if it's acceptable to always
have debug symbol available.
- However, some projects ignore all CFLAGS and CXXFLAGS;
- Some other projects relies on CMAKE_BUILD_TYPE=Release to install to
correct location and/or disable coverage.
- To get away with -O3, we need patching either ways, let's go with
CMAKE_BUILD_TYPE=None, and patch all problematic softwares.
make was accidentally left hardcoded to query if a test target was
available, which meant tests wouldn't be run for most of the
applications, since they were now using ninja.
Reason: https://gitlab.kitware.com/cmake/cmake/issues/19590
Our workaround within cmake is not sufficient as it does not
address the issue fully and things still break sometimes. So
work around this in the build-style for the time being (and
drop the cmake patch).
Once this is fixed upstream (probably needs special casing
for the -pipe flag and strip it during compile tests) we
can drop this.
ppc is the correct name which cmake reports in a native ppc32
environment, therefore the cross toolchain definition is wrong.
Closes: #12061 [via git-merge-pr]
Signed-off-by: Jürgen Buchmüller <pullmoll@t-online.de>
This reverts commit 6638dc5526.
Setting RelWithDebInfo can cause issues since cmake macros often handle
only Release or Debug build but not RelWithDebInf which might cause
issues https://github.com/void-linux/void-packages/pull/10948
It is advised to set -DCMAKE_BUILD_TYPE=RelWithDebInfo manually in
packages that ignore our CFLAGS or patch them to use them
closes#10948
This adds the build profiles for ppc64 targets as well as
modifications in other parts of the infra.
These targets are supported:
- ppc64le (glibc little endian elfv2)
- ppc64le-musl (musl little endian)
- ppc64-musl (musl big endian)
ELFv1 targets are explicitly not supported at this point.
Big endian musl supports ppc 970 or newer, while little endian
targets are set to a generic powerpc64le which effectively means
POWER8 and newer. Tuning is always set for POWER9, which is the
most likely target hardware. We also make sure AltiVec is always
on, because it is supported on all hardware we target.
[ci skip]
Many packages depending on Qt5 or Qt4 and built with cmake
generate "flags.make" files with -isystem for include paths.
With gcc6 this results in e.g. "#include_next <stdlib.h>" giving
an error, because a -isystem /usr/include is in the wrong place.
The simple fix is to replace "-isystem" with just "-I".
John
Đoàn Trần Công Danh
classabbyamp
Michal Vasilek
Joshua Krämer
Piotr Wójcik
Érico Rolim
q66
John
Foxlet
Enno Boland
maxice8
newbluemoon
Enno Boland
Leah Neukirchen
Jürgen Buchmüller
Alessio Sergi