This reverts commit d4736d53cd.
RtlGetVersion is a private API not meant for public use. Another
solution to detecting the Windows version will be needed.
Reported-by: Gilles Khouzam <Gilles.Khouzam@microsoft.com>
Since commit v3.1.0-rc1~635^2~7 (project: Add infrastructure for
recording CXX compiler features, 2013-10-17) we compile a test source to
a binary and then extract "<LANG>_FEATURES:..." strings from the binary
with the file(STRINGS) command. Add a newline at the beginning of the
string literal to be sure file(STRINGS) can extract the first entry as a
string independent of whatever else the compiler may put before the
storage it allocates for the literal within the binary.
04de9007 GHS: Fix generated file path slashes and quoting for 6.1.6
fbe0de92 GHS: Tell MULTI to delete .elf.ael file
63591b94 GHS: Find latest 'int' directory
Starting with OS X 10.11 there is a library called libnetwork
which will be picked up during curl configuration.
This breaks backward compatibility of the resulting binaries
because libnetwork is not available on older OS X versions.
Since commit v2.8.11~59^2 (cmSystemTools: Generalize TrimWhitespace to
all whitespace, 2013-03-27) we incorrectly use `c <= ' '` to determine
if `c` is a whitespace character. With a signed `char` type UTF-8
encoded strings may be truncated because values above 0x7f appear
negative and therefore less than 0x20. Use `isspace(c)` instead.
Extract the logic added by commit v3.1.0-rc1~386^2 (Encoding: Fix debug
asserts ... with non-ascii chars, 2014-06-16) into a helper function so
we can re-use it.
Mangling is prevented by using a function instead of a macro for setting
default value of some CPack variables. Function is meant for internal use
in CPack.cmake only.
Old macro is deprecated but kept for backwards compatibility - was
intended for internal use only as it can't be used for CPack after
CPack.cmake script is included.
Patch removes local workarounds that were required by old macro,
fixes default setting of variables that by default inherit value from
another variable that already went through old default setting macro
(e.g. value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY caused error for
wrong escapes if CPACK_PACKAGE_INSTALL_DIRECTORY contained escaped
back slashes) and provides a test for correct escaping of characters.
9cdf6ef4 Swift: Add proper Swift compiler test
1aa29f0d Swift: Remove positive Swift language tests
d778a1c2 Swift: Require Xcode 6.1 and for MacOS X at least SDK 10.10
4da60024 Swift: Fix Compiler-Id detection for Swift 2
874a265c Swift: Make SwiftMix compatible with Swift 2
The documetnation of binutils:
https://sourceware.org/binutils/docs/binutils/ar-cmdline.html
suggests to use the parameters "q" and "c" in this order ("q" is
operation, and "c" is the modifier).
Suggested-by: Дилян Палаузов <dilyan.palauzov@aegee.org>
Generally for a module foo, SWIG generates (in Python mode)
an extension module _foo.so and a proxy Python module foo.py.
However, if -noproxy is specified, instead it builds only foo.so
(without the leading underscore). The custom command generated
by CMake correctly handles the removal of this underscore when
-noproxy is given; however, it still adds foo.py to the expected
outputs. This upsets build tools that expect foo.py to be generated
(for example, 'make' will run the SWIG command twice). Fix this
by removing foo.py from the set of extra generated files when
-noproxy is specified.
b9856862 Tests: Cover set_property for buildsystem target properties
407ff47e cmTarget: Fix memory leak when SOURCES property is cleared
cf74fc24 cmTarget: Fix buildsystem property empty value set and append operations
8ea7611b find_program: Optionally consider all names in each directory
fc1990c9 cmFindProgramCommand: Re-implement search using more flexible approach
fdbfc9f6 Tests: Add explicit testing for find_program
907a919b cmSystemTools: Drop unused StringEndsWith method
ed4de3c9 cmFindProgramCommand: Use Names member instead of passing it
bf32b95e cmFindLibraryCommand: Avoid repeating search for the same name
It's relatively complex to determine in advance if a Xcode, SDK,
and Deployment Target configuration is capable of running Swift.
For example the following combinations do not work:
* deployment target < OS X 10.9
* Xcode 6.2 and macosx10.9 SDK
* Xcode 7 Beta 6 and macosx10.10 SDK
Until we found out how to query Xcode for Swift support in a reliable
way, the RunCMake.Swift test cases will be restricted to negative ones.
