This enables configuration of build parallelism with the Ninja generator by
passing arguments on the command line to CMake. For example,
cmake \
'-DCMAKE_JOB_POOLS:STRING=compile=5;link=2' \
-DCMAKE_JOB_POOL_COMPILE:STRING=compile \
-DCMAKE_JOB_POOL_LINK:STRING=link \
~/src/MyProject
Detect x32-abi through CMakeCompilerABI infrastruture and use this
information at runtime to determine the correct library paths with
`FIND_LIBRARY_USE_LIBX32_PATHS`.
Fixes: #15994
Add a new `CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX` variable to allow use
of a custom suffix on `lib` directory names. This is a more general
option than that added by commit v3.7.0-rc1~504^2 (Teach find_library
and find_package to search lib32 paths, 2016-06-10). It allows the find
path to be more deterministic on custom setups.
See discussion in #10287 and #15994.
When building with multiple SDKs within one project Xcode requires
the usage of ${EFFECTIVE_PLATFORM_NAME} to put temporary and build
outout into separate directories. For example an iOS device and
simulator build use two different SDKs (iphoneos and iphonesimulator).
In the past cmake tries to detect embedded toolchains that could
possibly use simulators and emitted EFFECTIVE_PLATFORM_NAME (EPN)
at the proper locations. In #16253 Mark noticed that if he
uses macosx and iphoneos in combination the necessary EPN is not
emitted. This is because CMake by default assumes macosx SDK which
does not trigger EPN emission.
The fist naive approach - enabling EPN unconditionally revealed that
then the EPN leaks into generator expressions like $<TARGET_FILE:xxx>
which might be a regression and thus is unacceptable.
The next approach was to add an CMake property to enable EPN emission
unconditionally. This solved the reported problem.
But the EPN leakage also happened for the embedded toolchains already
without anyone noticing. So the control property was turned into a
tri-state one:
* No definition: EPN is activated for embedded toolchains like before
* ON: EPN is always emitted
* OFF: EPN is never emitted
That approach gives the user the chance to disable EPN for embedded
toolchains and restores generator expression functionality for those.
Closes: #16253
A common use case of `target_compile_features` is simply to specify that
the compiler should be run in a mode that is aware of e.g. C++11. Some
projects simply specify a particular C++11-only feature to request this.
Provide a first-class way to do this by naming features after the
corresponding language standard. Record them as always available in the
corresponding standard level so that requesting them always ensures that
standard (or higher) is used.
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``.
Add a TARGET_MESSAGES property to control whether Makefile targets print
the "Built target " completion messages. Default to ON to preserve
existing behavior.
Extend sentences in other documentation linking to this manual to
say that it has a list of supported compilers.
Co-Author: Brad King <brad.king@kitware.com>
Link to it from the documentation of related properties, variables
and commands.
Extend the cmake-developer(7) documentation with notes on
extending feature support for compilers.
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
Paul "TBBle" Hampson