Some generated cm*Lexer.h headers define preprocessor macros normally
provided by <stdint.h>. The latter is included indrectly by cmMakefile.h
since commit 2268c41a (Optimize custom command full-path dependency
lookup, 2013-08-06). Adjust the order to avoid redefinition warnings.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ deec6b8a | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' beef6819..deec6b8a
Brad King (1):
e39f85e0 SystemTools: Activate EnableMSVCDebugHook under CTest
Burlen Loring (1):
1d882d4c SystemInformation : Better stack trace
Patrick Gansterer (2):
89e42c36 SystemTools: Remove duplicate code for parsing Windows registry keys
deec6b8a SystemTools: Add a function to get subkeys of a Windows registry key
Sean McBride (1):
4c4f8a9e Supress clang warnings about dynamic exception specifications
Change-Id: I37367dc5db58818d5954735e00c6d523a1dd1411
c90151b VS: Unify how the name of the generator is specified
3873d29 Fix detection of WinCE SDKs with 64bit verion of CMake
40a4302 VS12: Remove duplicated overload of UseFolderProperty()
b02f09d VS: Replace ArchitectureId with PlatformName
4b15dc8 VS: Set CMAKE_VS_PLATFORM_NAME for VS7 and VS71 too
60e568c VS10: Do not set the TargetMachine when detecting the compiler
dfbfe6f VS6: Hardcode id_machine_6 for compiler detection
In the common case of custom command dependencies specified via full
path optimize the implementation of GetSourceFileWithOutput using a
(hash) map. This is significantly faster than the existing linear
search. In the non-full-path case fall back to the existing linear
suffix search.
Teach modules CMakeDetermineCompiler and CMakeUnixFindMake to ask Xcode
where to find the compiler or make tools, using 'xcrun --find', if none
is found in the PATH. Teach module Platform/Darwin to add the path to
the SDK to CMAKE_SYSTEM_PREFIX_PATH so that find_* command look there.
Also add the SDK /usr/include directory to the implicit include list in
CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to suppress explicit -I
options for it.
bf5a5bc bootstrap: Do not suppress CMAKE_OSX_SYSROOT if CFLAGS have -isysroot (#14324)
95f78e0 OS X: Search for SDK based on deployment target (#14324)
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
The Microsoft linker is intelligent enough to detect the target
machine type depending on the input files. This allows us to
get the target architecture from the compiler instead of
maintaining the mapping to the platform name.
Revert commit a1c032b9 (bootstrap: Suppress CMAKE_OSX_SYSROOT if CFLAGS
have -isysroot, 2012-09-21). If MACOSX_DEPLOYMENT_TARGET is set then
CMAKE_OSX_DEPLOYMENT_TARGET will be set and Darwin.cmake will complain
if no CMAKE_OSX_SYSROOT is set. Just allow both -isysroot flags to
appear. The one generated by CMAKE_OSX_SYSROOT appears after and
overrides the one from CFLAGS/CXXFLAGS.
When available, use CMAKE_OSX_DEPLOYMENT_TARGET instead of the host OS X
version to select the default SDK. This makes sense because one should
use the SDK matching the deployment target.
Suggested-by: John Ralls <jralls@ceridwen.us>
* The ALIAS name must match a validity regex.
* Executables and libraries may be aliased.
* An ALIAS acts immutable. It can not be used as the lhs
of target_link_libraries or other commands.
* An ALIAS can be used with add_custom_command, add_custom_target,
and add_test in the same way regular targets can.
* The target of an ALIAS can be retrieved with the ALIASED_TARGET
target property.
* An ALIAS does not appear in the generated buildsystem. It
is kept separate from cmMakefile::Targets for that reason.
* A target may have multiple aliases.
* An ALIAS target may not itself have an alias.
* An IMPORTED target may not have an alias.
* An ALIAS may not be exported or imported.
Fix generation of the AdditionalIncludeDirectories element content to
escape for XML syntax. We already escape content of other elements,
this one was simply missing by accident.
Patrick Gansterer
Brad King
KWSys Robot
Nicolas Despres
Stephen Kelly
Daniele E. Domenichelli