If the cache variable TUKLIB_FAST_UNALIGNED_ACCESS is already set,
the autodetection result isn't needed because the option() command
does nothing when the cache variable is already set.
This is largely white space change to indent the if...endif block.
CMake >= 4.1 sets CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID on many
platforms. The list of possible values are documented. Use this
variable when available. On older CMake versions CMAKE_SYSTEM_PROCESSOR
is still used, thus the regexes have to include values like ^amd64 still.
With old CMake versions, checking CMAKE_C_COMPILER_ARCHITECTURE_ID
is somewhat useful with MSVC because CMAKE_SYSTEM_PROCESSOR might
not match the target architecture.
On ARM64, support for fast unaligned memory access was autodetected by
checking if __ARM_FEATURE_UNALIGNED is defined. However, at least GCC
versions up to 15.2.0 define the macro even when -mstrict-align has
been specified. Thus, autodetection with GCC doesn't work correctly,
and binaries built using -mstrict-align can be much slower than they
need to be, unless the user also passes --disable-unaligned-access
to configure or -DTUKLIB_FAST_UNALIGNED_ACCESS=OFF to cmake.
See the GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555
Workaround the issue by using heuristics with GCC on ARM64.
With Clang, the detection using __ARM_FEATURE_UNALIGNED works.
It also works with GCC on 32-bit ARM.
Fixes: e5f13a66567b ("tuklib_integer: Autodetect support for unaligned access on ARM.")
This still relies on CMAKE_SYSTEM_PROCESSOR. CMake 4.1 added more
CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID values to detect the arch in
a more defined manner, but 4.1 is too new to require for now.
Thanks-to: Li Chenggang <lichenggang@deepin.org>
Closes: https://github.com/tukaani-project/xz/pull/186
Revert back to a macro so that list(APPEND CMAKE_REQUIRED_DEFINITIONS)
will affect the calling scope. I had forgotten that while CMake
functions inherit the variables from the parent scope, the changes
to them are local unless using set(... PARENT_SCOPE).
This also means that the commit message in 5bb77d0920dc is wrong. The
commit itself is still fine, making it clearer that -DHAVE_SYS_PARAM_H
is only needed for specific check_c_source_compiles() calls.
Fixes: c1ea7bd0b60eed6ebcdf9a713ca69034f6f07179
Define NetBSD and Darwin/macOS feature test macros. Autoconf defines
these too (and a few others).
Define the macros on Windows except with MSVC. The _GNU_SOURCE macro
makes a difference with mingw-w64.
Use a function instead of a macro. Don't take the TARGET_OR_ALL argument
because there's always global effect because the global variable
CMAKE_REQUIRED_DEFINITIONS is modified.
Automatic word wrapping makes translators' work easier and reduces
errors like misaligned columns or overlong lines. Right-to-left
languages and languages that don't use spaces between words will
still need extra effort. (xz hasn't been translated to any RTL
language so far.)
v5.2 didn't build with CMake. Other branches had
include(CMakePushCheckState) in top-level CMakeLists.txt
which made the build work.
Fixes: 597f49b61475438a43a417236989b2acc968a686
A CMake option LARGE_FILE_SUPPORT is created if and only if
-D_FILE_OFFSET_BITS=64 affects sizeof(off_t).
This is needed on many 32-bit platforms and even with 64-bit builds
with MinGW-w64 to get support for files larger than 2 GiB.
HAVE_DECL_PROGRAM_INVOCATION_NAME is renamed to
HAVE_PROGRAM_INVOCATION_NAME. Previously,
HAVE_DECL_PROGRAM_INVOCATION_NAME was always set when
building with autotools. CMake would only set this when it was 1, and the
dos/config.h did not define it. The new macro definition is consistent
across build systems.
The syntax "if(DEFINED CACHE{FOO})" requires CMake 3.14.
In some other places the code treats the cache variables
like normal variables already (${FOO} or if(FOO) is used,
not ${CACHE{FOO}).
Thanks to ygrek for reporting the bug on IRC.
Seems that the phrase "add more quotes" from sh/bash scripting
applies to CMake as well. E.g. passing an unquoted list ${FOO}
to a function that expects one argument results in only the
first element of the list being passed as an argument and
the rest get ignored. Adding quotes helps ("${FOO}").
list(INSERT ...) is weird. Inserting an empty string to an empty
variable results in empty list, but inserting it to a non-empty
variable does insert an empty element to the list.
Since INSERT requires at least one element,
"${CMAKE_THREAD_LIBS_INIT}" needs to be quoted in CMakeLists.txt.
It might result in an empty element in the list. It seems to not
matter as empty elements consistently get ignored in that variable.
In fact, calling cmake_check_push_state() and cmake_check_pop_state()
will strip the empty elements from CMAKE_REQUIRED_LIBRARIES!
In addition to quoting fixes, this fixes checks for the cache
variables in tuklib_cpucores.cmake and tuklib_physmem.cmake.
Thanks to Martin Matuška for testing and reporting the problems.
These fixes aren't tested yet but hopefully they soon will be.
This does *NOT* replace the Autotools-based build system in
the foreseeable future. See the comment in the beginning
of CMakeLists.txt.
So far this has been tested only on GNU/Linux but I commit
it anyway to make it easier for others to test. Since I
haven't played much with CMake before, it's likely that
there are things that have been done in a silly or wrong
way and need to be fixed.
