specifying the type prevents cmake to converthing the paths
relative to the CWD
cmake documentation:
Furthermore, if the <type> is PATH or FILEPATH and the <value> provided
on the command line is a relative path, then the set command will treat
the path as relative to the current working directory and convert it to an absolute path.
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]
Đoàn Trần Công Danh
John
classabbyamp
Michal Vasilek
Joshua Krämer
Piotr Wójcik
Érico Rolim
q66
John
Foxlet
Enno Boland
maxice8
newbluemoon
Enno Boland