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.
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.
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.