CMake merge requestshttps://gitlab.kitware.com/cmake/cmake/-/merge_requests2016-11-01T09:15:27-04:00https://gitlab.kitware.com/cmake/cmake/-/merge_requests/214Updated FindMatlab.cmake2016-11-01T09:15:27-04:00Francesco RomanoUpdated FindMatlab.cmakeAdded Matlab2016b version (9.1)Added Matlab2016b version (9.1)3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/232CPackIFW: Updated search algorithm2016-11-04T08:28:53-04:00Konstantin PodsvirovCPackIFW: Updated search algorithmImproviments:
- Look for QtIFW distributed with QtSDK;
- Do not give a reason for the CMP0007 warning.Improviments:
- Look for QtIFW distributed with QtSDK;
- Do not give a reason for the CMP0007 warning.3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/292Renamed Visual Studio 15 generator2016-11-30T08:39:37-05:00RomanRenamed Visual Studio 15 generatorRenamed the Visual Studio 15 generator to it's final name which was announced at https://blogs.msdn.microsoft.com/visualstudio/2016/11/16/visual-studio-2017-rc/Renamed the Visual Studio 15 generator to it's final name which was announced at https://blogs.msdn.microsoft.com/visualstudio/2016/11/16/visual-studio-2017-rc/3.7.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/314FindBoost: Fix MSVC2017 compatibility2016-12-09T14:25:18-05:00Zheng LuoFindBoost: Fix MSVC2017 compatibilityMSVC2017 was released days ago, and `FindBoost` still cannot detect MSVC2017 correctly.
> -- The C compiler identification is MSVC 19.10.24629.0
>
> -- The CXX compiler identification is MSVC 19.10.24629.0MSVC2017 was released days ago, and `FindBoost` still cannot detect MSVC2017 correctly.
> -- The C compiler identification is MSVC 19.10.24629.0
>
> -- The CXX compiler identification is MSVC 19.10.24629.03.7.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/361FindBoost: Add support for 1.632017-01-11T10:05:18-05:00Roger LeighFindBoost: Add support for 1.63- Added 1.63.0 and 1.63 as supported versions
- Added the component dependencies for 1.63 (unchanged from 1.62)- Added 1.63.0 and 1.63 as supported versions
- Added the component dependencies for 1.63 (unchanged from 1.62)3.7.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/529Add -Wno-format-security to handle -Werror=format-security in Fedora flags2017-02-28T09:45:09-05:00Orion PoplawskiAdd -Wno-format-security to handle -Werror=format-security in Fedora flagsDue to gcc change for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677, cmake builds started to fail in Fedora Rawhide with:
```
/usr/lib64/ccache/gcc -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -I/builddir/build/BUILD/cmake-3.7.2/build/...Due to gcc change for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79677, cmake builds started to fail in Fedora Rawhide with:
```
/usr/lib64/ccache/gcc -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -I/builddir/build/BUILD/cmake-3.7.2/build/Utilities -I/builddir/build/BUILD/cmake-3.7.2/Utilities -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wno-format -std=gnu11 -o CMakeFiles/kwiml_test.dir/test.c.o -c /builddir/build/BUILD/cmake-3.7.2/Utilities/KWIML/test/test.c
cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]
cc1: some warnings being treated as errors
```
This fixes that. This will need to propagate to all KWIML users.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/528FindPkgConfig: use "library >= version" syntax instead of deprecated --atleas...2017-03-01T09:01:18-05:00Gautier Pelloux-PrayerFindPkgConfig: use "library >= version" syntax instead of deprecated --atleast-version syntaxFindPkgConfig module still uses the old syntax `--atleast-version <version> <pkg>`, `--max-version <version> <pkg>` and `--exact-version <version> <pkg>` instead of the new ways: `<pkg> >= <version>`, `<pkg> = <version>` and `<pkg> <= <v...FindPkgConfig module still uses the old syntax `--atleast-version <version> <pkg>`, `--max-version <version> <pkg>` and `--exact-version <version> <pkg>` instead of the new ways: `<pkg> >= <version>`, `<pkg> = <version>` and `<pkg> <= <version>`.
This is at least an issue for `pkgconf` which does not handle `--atleast-version` and such, see [upstream issue](https://github.com/pkgconf/pkgconf/issues/115).3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/541Update FindVulkan.cmake2017-03-03T08:00:06-05:00Brad DavisUpdate FindVulkan.cmakeAs of at least 1.0.42 of the LunarG SDK, the vulkan-1.lib file for windows is stored in ${VULKAN_SDK}/Lib or ${VULKAN_SDK}/Lib32As of at least 1.0.42 of the LunarG SDK, the vulkan-1.lib file for windows is stored in ${VULKAN_SDK}/Lib or ${VULKAN_SDK}/Lib323.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/598libarchive: backport rc4 crypto requirement update2017-03-22T08:49:36-04:00Brad Kinglibarchive: backport rc4 crypto requirement updateBackport upstream libarchive commit `70f497f456` (As per Cryptographic
Requirements, 2017-03-19). Discard more bytes of the RC4 keystream
to reduce the possibility of non-random bytes.Backport upstream libarchive commit `70f497f456` (As per Cryptographic
Requirements, 2017-03-19). Discard more bytes of the RC4 keystream
to reduce the possibility of non-random bytes.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/590Fix FindBoost.cmake to find Boost 1.64.0 beta2017-03-22T10:26:08-04:00Mateusz ŁoskotFix FindBoost.cmake to find Boost 1.64.0 betaMinimal update to the module to enable finding components of Boost **beta** from the upcoming release.
------
Boost 1.64.0 beta has been [published for testing](http://lists.boost.org/Archives/boost/2017/03/233332.php). The Boost 1...Minimal update to the module to enable finding components of Boost **beta** from the upcoming release.
------
Boost 1.64.0 beta has been [published for testing](http://lists.boost.org/Archives/boost/2017/03/233332.php). The Boost 1.64.0 beta snapshot recognises VS2017 toolset as `msvc-14.10` with library name tag generated as `vc1410` (see https://github.com/boostorg/config/pull/126).
Unfortunately, there is lots of confusion regarding versions uses in VS2017 and the toolset name used by Boost has not been fixed yet. Details in thread [1.64.0 Delayed because of Microsoft (version numbers)](http://lists.boost.org/Archives/boost/2017/03/233443.php). However, this small fix allows early testers to pass some initial hurdle.
This is a *minimal/preliminary* patch, it does not include update to inter-dependencies between Boost libraries.
I have successfully tested it using CMake 3.8.20170316-g2b86 with a Boost client project which requires:
```
-- Boost version: 1.64.0
-- Found the following Boost libraries:
-- date_time
-- chrono
-- filesystem
-- iostreams
-- program_options
-- regex
-- system
-- thread
-- zlib
```3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/607FindBoost: Update support for 1.64 (vc1410->vc141)2017-03-22T10:52:47-04:00Mateusz ŁoskotFindBoost: Update support for 1.64 (vc1410->vc141)* Take two of Boost toolset tag agreement for VS2017.
* Take one was vc150 -> vc1410 (see !590).
------
TL;TR: Boost folks agreed `vc141` tag and `b2 toolset=msvc=14.1`.
Related changes in Boost
* https://github.com/boostorg...* Take two of Boost toolset tag agreement for VS2017.
* Take one was vc150 -> vc1410 (see !590).
------
TL;TR: Boost folks agreed `vc141` tag and `b2 toolset=msvc=14.1`.
Related changes in Boost
* https://github.com/boostorg/config/pull/128
* https://github.com/boostorg/build/pull/183
Yesterday, corrected snapshot of Boost 1.64.0 (Beta) was released: http://lists.boost.org/Archives/boost/2017/03/233682.php
/cc @brad.king
Topic-rename: FindBoost-1.643.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/616InstallRequiredSystemLibraries: Add support for VS 20172017-03-24T08:37:56-04:00Brad KingInstallRequiredSystemLibraries: Add support for VS 2017VS 2017 (VS 15) places its redist DLLs in `Microsoft.VC150.*` directories but still uses version number `140` in the DLL names. The redist directories now have version numbers in their name, and the MSVC and MFC runtime DLLs may be in d...VS 2017 (VS 15) places its redist DLLs in `Microsoft.VC150.*` directories but still uses version number `140` in the DLL names. The redist directories now have version numbers in their name, and the MSVC and MFC runtime DLLs may be in directories with different versions. Fill out our logic to handle this.
For now assume we are given the `MSVC_REDIST_DIR` value as a cache entry. Unfortunately we cannot yet find the VS 2017 MSVC redist directory automatically since there is no registry entry for the VS installation. Later we will have to use `cmVSSetupHelper` for this.
Issue: #167353.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/628CPack/RPM tests: handle build-id links2017-03-27T09:09:43-04:00Domen VrankarCPack/RPM tests: handle build-id linksBuild id links generation was introduced
in rpm 4.13.0.1 so files related to them
should be ignored as they are not relevant
for the tests.
Fixes #16710Build id links generation was introduced
in rpm 4.13.0.1 so files related to them
should be ignored as they are not relevant
for the tests.
Fixes #167103.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/632InstallRequiredSystemLibraries: Find VS 2017 redist directory2017-03-28T10:15:00-04:00Brad KingInstallRequiredSystemLibraries: Find VS 2017 redist directoryAdd an undocumented `cmake_host_system_information` query to find the VS 2017 installation directory by asking the VS installer tool. Then look relative to that for the redist directory.
Fixes: #16737Add an undocumented `cmake_host_system_information` query to find the VS 2017 installation directory by asking the VS installer tool. Then look relative to that for the redist directory.
Fixes: #167373.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/638Swift: Default to Swift 3.0 with Xcode 8.3 and later2017-03-30T08:52:43-04:00Gregor JasnySwift: Default to Swift 3.0 with Xcode 8.3 and laterXcode 8.3 has dropped support for Swift 2.3 so that compiler and feature detection
failed.
Closes #16742Xcode 8.3 has dropped support for Swift 2.3 so that compiler and feature detection
failed.
Closes #167423.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/629FindBoost: Add Boost 1.64 dependencies2017-03-30T08:55:21-04:00Roger LeighFindBoost: Add Boost 1.64 dependencies- Add Boost 1.64 dependencies using the 1.64 beta1 headers (previously was a copy of the 1.63 dependencies)
May require a followup tweak in the unlikely event there are any dependency changes in the final release.
Topic-rename: Fin...- Add Boost 1.64 dependencies using the 1.64 beta1 headers (previously was a copy of the 1.63 dependencies)
May require a followup tweak in the unlikely event there are any dependency changes in the final release.
Topic-rename: FindBoost-1.64-deps3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/644SDCC: Fix identification of current sdcc compiler2017-03-30T08:59:06-04:00Brad KingSDCC: Fix identification of current sdcc compilerThe sdcc compiler no longer defines the `SDCC` preprocessor macro. Instead `__SDCC_VERSION_MAJOR` and similar component-wise macros are defined. Use them instead if defined.
Issue: #16746The sdcc compiler no longer defines the `SDCC` preprocessor macro. Instead `__SDCC_VERSION_MAJOR` and similar component-wise macros are defined. Use them instead if defined.
Issue: #167463.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/658CMakeParseImplicitLinkInfo: Ignore ld -lto_library flag2017-04-04T09:18:41-04:00Brad KingCMakeParseImplicitLinkInfo: Ignore ld -lto_library flagThe `ld` tool in Xcode 8.3 now has a `-lto_library <path>` flag. Ignore the flag instead of accidentally parsing it as `-l` with `to_library`.
Fixes: #16766The `ld` tool in Xcode 8.3 now has a `-lto_library <path>` flag. Ignore the flag instead of accidentally parsing it as `-l` with `to_library`.
Fixes: #167663.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/676FindwxWidgets: link with the new required libs under MSW2017-04-10T09:42:55-04:00VZFindwxWidgets: link with the new required libs under MSWLatest wxWidgets git master version and the upcoming 3.1.1 release requires
linking with shlwapi and version DLLs. As this does no harm when using the
previous versions, just do it unconditionally.Latest wxWidgets git master version and the upcoming 3.1.1 release requires
linking with shlwapi and version DLLs. As this does no harm when using the
previous versions, just do it unconditionally.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/633Ninja: Fix unrestricted sysconf() returns2017-04-14T21:41:23-04:00Christian PfeifferNinja: Fix unrestricted sysconf() returnsAs observed in https://gitlab.kitware.com/cmake/cmake/issues/16740 , the `calculateCommandLineLengthLimit` incorrectly treats -1 returns from `sysconf()` calls as numerical -1 whereas it represents an undefined limit, i.e. infinity.
G...As observed in https://gitlab.kitware.com/cmake/cmake/issues/16740 , the `calculateCommandLineLengthLimit` incorrectly treats -1 returns from `sysconf()` calls as numerical -1 whereas it represents an undefined limit, i.e. infinity.
Given this value is only defined for limit queries, it should be only needed for the query to `_SC_MAX_ARG`.
Fixes: #16740
Topic-rename: ninja-fix-sysconf-non-limit3.8.0Brad KingBrad King