AppleClang does not support the cxx_thread_local feature, even
though it is based on a Clang version which does support the
feature.
http://stackoverflow.com/a/23850891/2428389
A possible reason for that is that thread_local might be used as
a variable in existing Apple SDK headers.
Extend the WriteCompilerDetectionHeader module to generate a define
for that feature with portability fallbacks. For the avoidance of
making it easy to write code which looks correct but which has odd
runtime behavior, don't set the define symbol at all if no
equivalent keyword is known.
07fc7b75 Tests: Test using objects from a language enabled in a subdirectory (#15325)
fdbfcfdf Ninja: Generate rules only for languages compiled in a target (#15325)
The SunPro Fortran compiler uses "-F" instead of "-E" to request
preprocessing. The output does not go to stdout so use "-o" to
specify the output file.
This fixes the guess originally made by commit b6b37e30 (Makefile: Add
assembly and preprocessed targets for Fortran, 2014-11-05).
bb83cdaa Help: Add notes for topic 'AppleClang-5.1-features'
bd6b42c1 Features: Record for AppleClang 5.1
b341799e Tests: Fix RunCMake.CompileFeatures test NonValidTarget2 case
e2a489c7 Remove some temporary vectors for ExpandListArgument.
0f99feec cmGeneratorExpression: Remove unused header.
722f1a71 CTest: Expand a string directly into a container.
The change in commit v3.1.0-rc1~174^2 (Makefile: Handle '#' in
COMPILE_OPTIONS, 2014-08-12) was not compatible with code that
tries to workaround the original bug. Unfortunately there is no
good way to fix the bug in a compatible way. Add a release note
to call attention to the change.
Add a test case that enables CXX in the top level and C in a subdirectory.
Create an executable in the top level that uses C objects compiled in the
subdirectory. Strictly speaking this is not defined behavior for all
language combinations, but happens to work in this case. Test this
behavior since projects might try to use it.
Refactoring in commit v3.1.0-rc1~688^2~2 (cmTarget: Compute languages
from object libraries on demand, 2014-03-18) taught cmTarget::GetLanguages
to (correctly) include the languages of object library sources. Previously
this was done only in cmTarget::ComputeLinkImplementationLanguages to
choose the linker language.
The Ninja generator writes out generic build rules for each language
compiled within a target using the rule variables defined in the
directory of the target. This only needs to be done for languages
actually compiled within the current target. Switch from using the
cmTarget::GetLanguages method to get the list of languages over to
using cmTarget::GetSourceFiles directly so we do not get the languages
in object libraries.
Strictly speaking this should make no difference because it is not safe
to use objects from a language not enabled in the directory containing
a target or else the link information for the language may not be
considered. However, in cases when no link information happens to be
needed for a language it was possible in CMake 3.0 and below to enable
a language only in a subdirectory providing an object library, and then
use the objects from a containing directory. The above change teaches
the Ninja generator to continue working in this case.
Mark the generated source file with the GENERATED property explicitly
since it is not marked automatically as the output of any custom
command. Mark both the 0 and 1 variants so it works no matter the
outcome of the generator expression.
For the nightly binaries, turn of CMAKE_USE_OPENSSL on Windows and OS X
10.6+ platforms. This will activate the new curl behavior to use the
OS-native SSL/TLS implementation.
Stephen Kelly
Kitware Robot
Brad King
Christoph Grüninger
Rolf Eike Beer
Clinton Stimpson
Daniele E. Domenichelli
Vladislav Vinogradov
Calin Cascaval