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.
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_EXE_LINKER_FLAGS_INIT "...")
to
string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_C_FLAGS_INIT "...")
to
string(APPEND CMAKE_C_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
Automate the conversion with:
sed -i 's/set *(\(CMAKE_\(C\|CXX\|Fortran\|RC\|ASM\|${[^}]\+}\)_FLAGS\(_[^_]\+\)\?_INIT \+"\)/string(APPEND \1 /' \
Modules/Compiler/*.cmake Modules/Platform/*.cmake
and follow up with some manual fixes (e.g. to cases that already
meant to append). Also revert the automated changes to contexts
that are not protected from running multiple times.
Migrate from the old `<os>-<cc>.cmake` layout to the modern
`<os>-<id>-<lang>.cmake` layout. Keep settings common to C and C++ in a
`Windows-OpenWatcom.cmake` helper module with an include blocker.
For now just add both C and CXX settings in the helper module.
Teach `Modules/Platform/Windows-MSVC.cmake` not to use MSVC options
for Fortran. We use the `__windows_compiler_msvc` for the Intel
Fortran compiler on Windows for other settings, but we do not want
the flags.
Previously this worked only because the options were later overridden
by `Modules/Platform/Windows-Intel*.cmake`, but it is cleaner to not
set the options in the first place.
In commit v3.6.0-rc1~279^2~10 (VS: in Clang/C2 toolset, setup correct
compiler settings, 2016-02-18) a flag mapping was added for the clang
`-Os` flag. However, this collides with a mapping we already had for
the MSVC flag of the same name. This is a symptom of a larger problem
in that the VS generators need a per-toolset flag map (issue #16153).
For now, simply drop the new mapping and drop `-Os` from clang compiler
flags in the MinSizeRel configuration.
Reported-by: Felix Bruns <felixbruns@gmail.com>
Add a ``FIND_LIBRARY_USE_LIB32_PATHS`` global property analogous to the
``FIND_LIBRARY_USE_LIB64_PATHS`` property. This helps find commands on
multilib systems that use ``lib32`` directories and either do not have
``lib`` symlinks or point ``lib`` to ``lib64``.
Rename Modules/Platform/<os>-<lang>.cmake files to
Modules/Platform/<os>-Determine-<lang>.cmake to clarify their role.
For compatibility with user-provided modules, load the old names
if they exist.
OS X supports using the SDK for any version equal to or newer than
the deployment target. There is no reason to warn if the versions
do not match exactly.
Suggested-by: James Burgess <jamesrburgess@mac.com>
Suggested-by: Clinton Stimpson <clinton@elemtech.com>
The `CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH` is used by CMake to always
append `-Wl,-blibpath:/usr/lib:/lib` to the link line. This is needed
by default on these platforms but needs to be overridden in some use
cases (e.g. an environment in which one maintains versioned shared
libraries). Change our logic to set this value only if it not already
set by the user, project, or toolchain file.
We define `NDEBUG` without a space after the `-D` option for most
compilers. Remove the space for MSVC (and Intel Fortran) for
consistency. The MS compiler technically does not document that
the `-D` argument may be separated from its value, though every
version to date supports it.
This placeholder was added to the compilation rules for other languages
by commit v3.4.0-rc1~342^2 (Factor an <INCLUDES> placeholder out of
<FLAGS> in rule variables, 2015-07-13) but ASM was incorrectly left out.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
Since commit v3.1.0-rc1~564^2 (OS X: Use -iframework for system
framework directories, 2014-05-05) we test the version of Clang is smaller
that 3.1 to see if it supports -iframework.
Considering that "iframework" support has been added in clang@r142418
(Frontend: Support -iframework.) prior to clang 3.1, this made sense.
That said, considering that support for multiple -iframework parameters
has been added later in clang@r164607 (-iframework should allow separate
arguments. ) prior to clang 3.2, this commit updates the check to enable
framework support only if version is >= 3.2
In Modules/Platform/WindowsPaths.cmake our previously recorded
environment variable combinations no longer seem to be correct. For
example, a 64-bit cmake binary may see ProgramW6432 in the environment
and end up not considering the "ProgramFiles(x86)" variable. Instead
check for all possible environment variables in the preferred order and
then remove duplicates.
Reported-by: Shawn Waldon <shawn.waldon@kitware.com>
Brad King
Chuck Atkins
Patrick Welche
Daniel Pfeifer
Wu Zhao
Daniel Scharrer
Michał Górny
Matthew Hanna
Felix Geyer
Gregor Jasny
Han Sangjin
Mariusz Pluciński
Jean-Christophe Fillion-Robin