CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-10-03T08:04:38-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/18239cmake 3.12 fail to generate csproj project with linked c++ library2018-10-03T08:04:38-04:00Jacob Lauritsencmake 3.12 fail to generate csproj project with linked c++ libraryIn CMAKE 3.12.0 this CMakeLists.txt fail to generate a csproj project file for project 'ShouldBeCSharpProject'.
In CMAKE 3.11.4, the project 'ShouldBeCSharpProject' is a csproj.
Adding the 'Example' as a subdirectory creates a csproj in...In CMAKE 3.12.0 this CMakeLists.txt fail to generate a csproj project file for project 'ShouldBeCSharpProject'.
In CMAKE 3.11.4, the project 'ShouldBeCSharpProject' is a csproj.
Adding the 'Example' as a subdirectory creates a csproj in build.
Removing the last line ('target_link_libraries (ShouldBeCSharpProject PUBLIC cpp_submodule)'), and the project is generated correctly.
[CMakeLists.txt](/uploads/cb238104ff9fe19f63a2544a1b46d5c3/CMakeLists.txt)
fully minimal working example: [cmake_312_csharp_bug.7z](/uploads/25523c26349e03a319c2bd138c3226c7/cmake_312_csharp_bug.7z)3.12.3Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/18338ctest --test-load is broken in CMake 3.11.22018-09-20T06:45:54-04:00tsondergaardctest --test-load is broken in CMake 3.11.2"ctest --test-load X" no longer waits for the load average to fall below X before starting a new test. Instead it gives up immediately. I tested this on Fedora 28 using the distro provided cmake 3.11.2. Using the following approach:
*..."ctest --test-load X" no longer waits for the load average to fall below X before starting a new test. Instead it gives up immediately. I tested this on Fedora 28 using the distro provided cmake 3.11.2. Using the following approach:
* Start "ctest --test-load 3" on a project where tests are slow enough to take long enough for this experiment
* Create an artificial load. I just ran "while true; do echo foo; done" in 4 other shells
When the loadavg reaches 3 ctest stops immediately after printing
```
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test vdbclient-test requires 1*****
```
I ran the same experiment with ctest from 3.10.3 and it waits nicely:
```
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
***** WAITING, System Load: 3, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
***** WAITING, System Load: 4, Max Allowed Load: 3, Smallest test evncserver-test requires 1*****
```
The exact ctest command I used: ctest --output-on-failure --timeout 1800 -j 3 --test-load 3"3.12.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18347ctest_start() reads TAG file ignoring the TRACK argument2018-09-11T08:18:11-04:00Ben Boeckelctest_start() reads TAG file ignoring the TRACK argumentStarting in 3.12.x, likely due to !2036, when a CTest script uses `ctest_start(Experimental TRACK t)`, if a previous build ran with another track and the build tree was not cleaned out, the track read from the `Testing/Temporary/TAG` fil...Starting in 3.12.x, likely due to !2036, when a CTest script uses `ctest_start(Experimental TRACK t)`, if a previous build ran with another track and the build tree was not cleaned out, the track read from the `Testing/Temporary/TAG` file causes CTest to ignore the `TRACK` argument to `ctest_start`. The MR mentions that it only affects `ctest_start(APPEND)`, but this seems to not be the case.
FWIW, this is causing Kitware's buildbot infrastructure to submit MR builds to other tracks such as `Nightly` or `master` since those builds are clean and MR builds are not, the clean build's track overwrites the intended MR track submission.
Cc: @robertmaynard @shawn.waldon @brad.king @kyle.edwards3.12.3Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/18349MPI_COMPILE_FLAGS is list instead of a string2019-09-20T13:09:54-04:00Christoph JunghansMPI_COMPILE_FLAGS is list instead of a stringIn CMake-3.11.4 and CMake-3.12.1 `MPI_COMPILE_FLAGS` is a list and hence adding it to e.g. CMAKE_CXX_FLAGS will lead to semicolons being injected.
When running `mpicc --showme` it outputs
```
-fexceptions -pthread
```
so there are two c...In CMake-3.11.4 and CMake-3.12.1 `MPI_COMPILE_FLAGS` is a list and hence adding it to e.g. CMAKE_CXX_FLAGS will lead to semicolons being injected.
When running `mpicc --showme` it outputs
```
-fexceptions -pthread
```
so there are two compile flags here.
When now using a `CMakeLists.txt` like:
```cmake
cmake_minimum_required(VERSION 3.1)
find_package(MPI)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${MPI_COMPILE_FLAGS}")
message("CXX_FLAGS: ${CMAKE_CXX_FLAGS}")
```
one will get an output like:
```
CXX_FLAGS: -fexceptions;-pthread
```
which will lead to compile errors.
As a side note in CMake-3.9.6 this isn't a problem as `-pthread` doesn't get added to `MPI_COMPILE_FLAGS` and hence there is only one item in the list.
Found here: https://github.com/espressomd/espresso/pull/2244
Workaround is pretty simple:
```diff
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -286,7 +286,10 @@ endif(WITH_VALGRIND_INSTRUMENTATION)
#######################################################################
find_package(MPI REQUIRED)
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${MPI_COMPILE_FLAGS}")
+# Workaround for https://gitlab.kitware.com/cmake/cmake/issues/18349
+foreach(_MPI_FLAG ${MPI_COMPILE_FLAGS})
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${_MPI_FLAG}")
+endforeach()
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${MPI_LINK_FLAGS}")
include_directories(SYSTEM ${MPI_INCLUDE_PATH})
list(APPEND LIBRARIES ${MPI_LIBRARIES})
```3.12.3Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18361FindDoxygen broken2018-09-12T09:35:48-04:00Stephan GatzkaFindDoxygen brokenRunning cmake version 3.12, if I run find_package(Doxygen) I get the following warning, which results in an error:
```
CMake Warning (dev) in /usr/share/cmake-3.12/Modules/FindDoxygen.cmake:
Policy CMP0057 is not set: Support new ...Running cmake version 3.12, if I run find_package(Doxygen) I get the following warning, which results in an error:
```
CMake Warning (dev) in /usr/share/cmake-3.12/Modules/FindDoxygen.cmake:
Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake
--help-policy CMP0057" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
IN_LIST will be interpreted as an operator when the policy is set to NEW.
Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
src/CMakeLists.txt:5 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at /usr/share/cmake-3.12/Modules/FindDoxygen.cmake:580 (elseif):
given arguments:
"NOT" "doxygen" "IN_LIST" "Doxygen_FIND_COMPONENTS"
Unknown arguments specified
Call Stack (most recent call first):
src/CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
See also "/tmp/cio/CMakeFiles/CMakeOutput.log".
```
3.12.3Brad KingBrad King