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.
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
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.
The Watcom compiler does not have stream operators for std::string.
Since KWSys no longer provides the operators for us, just use c_str()
to avoid the problem and allow the test to compile on Watcom.
Extend the RunCMake.set_property test with cases covering buildsystem
target properties:
* COMPILE_DEFINITIONS
* COMPILE_FEATURES
* COMPILE_OPTIONS
* INCLUDE_DIRECTORIES
* LINK_LIBRARIES
* SOURCES
Also test a non-buildsystem property to document the current difference
in behavior. Refactor the existing LINK_LIBRARIES case to the same
more-extensive test as the rest. Use the output generated by CMake 3.3
as the expected output for each test case.
Refactoring in commit 1f54bc1c (cmTarget: Split storage of include
directories from genexes, 2015-08-04), commit 772ecef4 (cmTarget: Split
storage of compile options from genexes, 2015-08-04), commit 44e071ae
(cmTarget: Split storage of compile features from genexes, 2015-08-04),
and commit 197f4de1 (cmTarget: Split storage of compile definitions from
genexes, 2015-08-04) failed to account for value==NULL in SetProperty
and AppendProperty methods.
The test case added to RunCMake.set_property by commit 675ef165 (Allow
LINK_SEARCH_{START,END}_STATIC props to have default values, 2015-08-07)
is not a test of the set_property command and so belongs in its own test
case. Create a new RunCMake.LinkStatic test to cover cases related to
static linking.
While at it, simplify the LINK_SEARCH_STATIC test case to enable only C.
Our upstream-built release tarballs already contain many unversioned
paths and so will never overlap with another version of CMake in the
same installation prefix. Therefore we do not need a versioned name for
the documentation directory. Configure our release binaries to place
the documentation in an unversioned directory so that one can use the
same path to refer to the documentation locally even after updating
CMake. For example, on OS X one may see the documentation in
`/Applications/CMake.app/Contents/doc/cmake/html/index.html`.
Add an OPENSSL_USE_STATIC_LIBS option to enable it. Adjust
CMAKE_FIND_LIBRARY_SUFFIXES to only look for .a and .lib files. Also
adjust the search paths on Windows for installer locations of static
libraries.
Provide each variant in ZLIB_LIBRARIES and ZLIB::ZLIB imported location
properties when one is found, while maintaining support for manually
setting the library via ZLIB_LIBRARY.
KWSys has removed support for kwsys_ios, kwsys_stl, and pre-c++98
template compatibility layers. Drop the bootstrap script checks for
these and configuration of the compatibility headers we no longer use.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ dc3fdd7f | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' cdaf522c..dc3fdd7f
Brad King (9):
15a16826 Remove include <kwsys/ios/*> and kwsys_ios:: compatibility layer
a5799c17 Remove unused KWSYS_IOS_USE_{SSTREAM,STRSTREAM_H,STRSTREA_H} checks
198957cf Remove unused KWSYS_IOS_USE_SSTREAM check
24d2b60e Remove support for pre-C++98 streams
2a581c30 Remove support for pre-C++98 std::string missing operators
5f3fd465 Remove support for pre-C++98 STL
cded1574 Remove support for pre-C++98 STL from hash_map and hash_set
f130a3ab Remove kwsys/cstddef compatibility header
dc3fdd7f Remove support for pre-C++98 template capabilities
When more than one value is given to the NAMES option this command by
default will consider one name at a time and search every directory for
it. Add a NAMES_PER_DIR option to tell this command to consider one
directory at a time and search for all names in it.
Avoid using KWSys SystemTools::FindProgram because it does much more
than we actually need for find_program and does not allow us to control
the order of preference between directories and names. Create our own
cmFindProgramHelper much like cmFindLibraryHelper but without all the
find_library-specific parts.
Previously this command was tested only implicitly as part of larger
tests. Add a RunCMake.find_program test to cover find_program cases
specifically and independently.
In FindNormalLibraryDirsPerName we consider one name at a time and
search the entire path. Avoid repeated consideration of names by
removing each one from the list of candidates before considering the
next one. This will not change behavior because we already know the
earlier candidates were not found on repeated considering anyway.
Determine the Desktop SDK for Windows Phone and Windows Store from the
generator instead of the version of the targeted app. This allows to
build a Windows Phone 8.1 app on VS 2015 for example.