CMake merge requestshttps://gitlab.kitware.com/cmake/cmake/-/merge_requests2017-09-20T07:50:58-04:00https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1289CTest: fix crash if source file for coverage cannot be found2017-09-20T07:50:58-04:00Rolf Eike BeerCTest: fix crash if source file for coverage cannot be foundThe opened XML elements were not closed, so an assert was triggered when the file was finally closed. If CMake is built with assertions disabled then an invalid XML file will be produced.
A testcase can be found in #17293.The opened XML elements were not closed, so an assert was triggered when the file was finally closed. If CMake is built with assertions disabled then an invalid XML file will be produced.
A testcase can be found in #17293.3.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/1280FindBoost: Add support for Boost 1.65.0 and 1.65.1 to CMake 3.92017-09-18T09:04:32-04:00Brad KingFindBoost: Add support for Boost 1.65.0 and 1.65.1 to CMake 3.9Backport the changes from !1172 and !1241 to CMake 3.9.
Fixes: #17289Backport the changes from !1172 and !1241 to CMake 3.9.
Fixes: #172893.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/1273vim: Revert "no tab in CMake-files"2017-09-18T17:10:12-04:00Maarten de Vriesvim: Revert "no tab in CMake-files"At some point `setlocal et` was added to `indent/cmake.vim` without much of an explanation. The commit message was "no tab in CMake-files".
Personally, I always use tabs to indent cmake files. To my knowledge there is no reason why th...At some point `setlocal et` was added to `indent/cmake.vim` without much of an explanation. The commit message was "no tab in CMake-files".
Personally, I always use tabs to indent cmake files. To my knowledge there is no reason why that would cause problems. Using tabs or spaces is a personal choice (and the subject of many holy wars), so I would prefer if cmake does not try to enforce anything here.
Instead, I feel cmake should respect whatever choice the user made in their own vim configuration.
Topic-rename: revert-vim-no-tabs
3.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/1258bootstrap: Fix running multiple times in-source2017-09-14T07:41:24-04:00Brad Kingbootstrap: Fix running multiple times in-sourceSince !691 we include `cmConfigure.h` via `""` instead of `<>`.
This breaks the `bootstrap` script when run more than once in an
in-source build. In that case `cmConfigure.h` is generated next
to the source files that include it, so `""...Since !691 we include `cmConfigure.h` via `""` instead of `<>`.
This breaks the `bootstrap` script when run more than once in an
in-source build. In that case `cmConfigure.h` is generated next
to the source files that include it, so `""`-style includes prevent the
`Bootstrap.cmk/cmConfigure.h` file from being included during bootstrap.
Fix this by teaching the bootstrap script to remove any `cmConfigure.h`
that may have been generated by an earlier run in an in-source build.
Fixes: #170823.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/1257Autogen: Autogen target dependency as file dependency fix2017-09-14T10:32:17-04:00Sebastian HoltermannAutogen: Autogen target dependency as file dependency fixTarget dependencies of the origin target were mistakenly
forwarded to the **_autogen** target as *file* dependencies.
This patch introduces proper distinction between *target*
and *file* dependencies of the **_autogen** target.
Closes #...Target dependencies of the origin target were mistakenly
forwarded to the **_autogen** target as *file* dependencies.
This patch introduces proper distinction between *target*
and *file* dependencies of the **_autogen** target.
Closes #172783.9.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/1256VS: Do not consider MAP_IMPORTED_CONFIG_<CONFIG> on non-imported targets2017-09-14T07:41:24-04:00Brad KingVS: Do not consider MAP_IMPORTED_CONFIG_<CONFIG> on non-imported targetsSince !669 we accidentally honor `MAP_IMPORTED_CONFIG_<CONFIG>` while generating the `.sln` file entries for normal targets. This causes `devenv.com`-driven builds to use the mapping incorrectly for normal targets. Check that a target ...Since !669 we accidentally honor `MAP_IMPORTED_CONFIG_<CONFIG>` while generating the `.sln` file entries for normal targets. This causes `devenv.com`-driven builds to use the mapping incorrectly for normal targets. Check that a target really comes from `include_external_msproject` before considering the map.
Furthermore, when we do use the map, we should only take the first entry if more than one configuration is specified. Otherwise we end up giving VS a configuration name with a `;` in it.
Fixes: #172763.9.3Brad KingBrad King