CMake now supports cross compiling for Android using the NDK or a
standalone toolchain. Document the associated variables and how how to
write toolchain files for Android.
Populate standard include directories and link libraries for the
platform. Select the STL corresponding to CMAKE_ANDROID_STL_TYPE and
matching the current ABI and toolchain to be used. Refer to the NDK
sources/cxx-stl/*/Android.mk files for the needed file locations.
Android NDK builds are always `debug` or `release`. We may populate
flags for these configurations that are needed to produce compatible
binaries. Ensure they are used by default.
The Android NDK source repository at
https://android.googlesource.com/platform/ndk.git
has `<ndk>/build/core/toolchains/*/setup.mk` files that store tables of
information for their build system. Add an equivalent file for each
compiler/abi combination.
Commonly used Android toolchain files that pre-date CMake upstream
support may need to be updated to work with our new functionality.
They typically set CMAKE_SYSTEM_VERSION to 1, so detect that and
skip our upstream Android settings. When such toolchain files are
updated to account for our upstream support, they can then set
CMAKE_SYSTEM_VERSION to a valid Android API and get new behavior.
Commonly used Android toolchain files that pre-date CMake upstream
support use a few environment and CMake variables as search locations.
Use them too to aid transition.
Compute CMAKE_SYSROOT automatically for the current API and architecture
selection. This causes the --sysroot option to be passed to GNU and
Clang compilers.
Store the Android API level in CMAKE_SYSTEM_VERSION. If it is not
provided by the user, initialize it from CMAKE_ANDROID_API or fall back
to finding the latest available in the NDK.
Support for NVIDIA Nsight Tegra Visual Studio Edition was previously
implemented in the CMake VS IDE generators. Avoid interfering with
that functionality for now. Later we may try to integrate this.
Provide a way for Platform/<os>-Determine-<lang>.cmake modules to save
platform-specific information about the compiler in the configured
CMake<lang>Compiler.cmake modules.
Once CMAKE_SYSTEM_NAME is known, load a platform-specific
Platform/<os>-Determine
module in order to enable custom determination of the other settings
needed for the CMakeSystem module (e.g. CMAKE_SYSTEM_PROCESSOR). Also
add a hook in Modules/CMakeSystem.cmake.in to allow platform-specific
information to be saved.
3a5f609c cmCryptoHash: New ByteHash methods that return a byte vector
f582dba6 cmCryptoHash: Return byte vector from internal Finalize method
74f0d4ab cmCryptoHash: New byte hash to string function
94c29976 cmCryptoHash: Documentation comments
Some callers may want the raw byte vector instead of the hex character
string. Convert the internal implementation to use this so that we
can later add public APIs to get it.
With the Makefile generator one can use `cd $subdir; make install` to build and
install targets associated with a given subdirectory. This is not possible to
do with the Ninja generator since there is only one `build.ninja` file at the
top of the build tree. However, we can approximate it by allowing one to run
`ninja $subdir/install` at the top of the tree to build the targets in the
corresponding subdirectory and install them.
This also makes sense for `test`, `package`, and other GLOBAL_TARGET targets.
It was already done for `all` by commit v3.6.0-rc1~240^2~2 (Ninja: Add
`$subdir/all` targets, 2016-03-11).
In cmGlobalNinjaGenerator::AppendTargetOutputs we previously
handled GLOBAL_TARGET outputs specially in order to avoid adding
directory components to the output. However, this is not necessary
because cmNinjaTargetGenerator::New already filters out copies of
these targets that are not at the top level. Instead we can simply
follow the same output computation code path as UTILITY targets.
CMake used to put all header search paths into HEADER_SEARCH_PATHS
attribute. Unfortunately this attribute does not support to declare
a search path as a system include.
As a hack one could add a -isystem /path to the cflags but then include
ordering is not deterministic. A better approach was chosen with this
patch by not filling HEADER_SEARCH_PATHS at all and to populate
the C, C++, and Fortran flags directly. The include paths used by
Xcode should be now identical to the ones used by Unix Makefiles and
Ninja generator.
The Numerical Algorithms Group (NAG) Fortran compiler documents -PIC for
position-independent code and does not have a separate option for PIE.
We added `-PIC` for PIC in commit v2.8.11~174^2 (NAG: Use -PIC for
Fortran position-independent code, 2013-02-18). Follow up for PIE.
Closes: #16236
The implementation of `install(EXPORT)` generates files into a staging
directory for later installation. We use the full install destination
in the path to the staging directory to avoid collisions. In order to
avoid exceeding maximum path lengths (especially on Windows) we compute
a hash of the install destination when it is too long. Fix this logic
to account for the length of the file name(s) when deciding whether to
switch to the hashed name.
Reported-by: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
Brad King
Kitware Robot
Sebastian Holtermann
Chaoren Lin
Gregor Jasny
Neil Carlson
Chuck Atkins
Daniel Pfeifer