CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-02-20T16:28:55-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/16308Documentation for CMAKE_COMPILER_IS_GNU&lt;LANG&gt; is incorrect2018-02-20T16:28:55-05:00Tobias HungerDocumentation for CMAKE_COMPILER_IS_GNU<LANG> is incorrectcmake --help-variable-list lists `CMAKE_COMPILER_IS_GNU<LANG>`.
The documentation is incorrect in that a compiler name (CXX, CC, G77, etc.) is needed, not the target language of the compiler.cmake --help-variable-list lists `CMAKE_COMPILER_IS_GNU<LANG>`.
The documentation is incorrect in that a compiler name (CXX, CC, G77, etc.) is needed, not the target language of the compiler.https://gitlab.kitware.com/cmake/cmake/-/issues/16146documentation of add_custom_target: describe possible values of COMMAND argument2017-10-13T13:17:56-04:00Joachim Wuttkedocumentation of add_custom_target: describe possible values of COMMAND argumentThe CMake commands add_custom_target and add_custom_command (and others?) have an argument COMMAND. The documentation currently does not say what sort of commands are meant to be valid arguments here. After long research, I found that a ...The CMake commands add_custom_target and add_custom_command (and others?) have an argument COMMAND. The documentation currently does not say what sort of commands are meant to be valid arguments here. After long research, I found that a partial answer is provided by "cmake -E help". It would certainly be helpful if this and more information were provided, or linked to, on the doc pages of add_custom_target, add_custom_command etc.https://gitlab.kitware.com/cmake/cmake/-/issues/16235Documentation of how to use variables in macros is confusing, possible incorrect2017-10-13T13:17:56-04:00vitaly-kruglDocumentation of how to use variables in macros is confusing, possible incorrectReferring to https://cmake.org/cmake/help/v3.5/command/macro.html?highlight=macro, I see two problems:
PROBLEM 1:
```
Therefore you will NOT be able to use commands like:
if(ARGV1) # ARGV1 is not a variable
if(DEFINED ARGV2) # A...Referring to https://cmake.org/cmake/help/v3.5/command/macro.html?highlight=macro, I see two problems:
PROBLEM 1:
```
Therefore you will NOT be able to use commands like:
if(ARGV1) # ARGV1 is not a variable
if(DEFINED ARGV2) # ARGV2 is not a variable
if(ARGC GREATER 2) # ARGC is not a variable
foreach(loop_var IN LISTS ARGN) # ARGN is not a variable
```
But then, in a subsequent example on the same macro documentation page, it uses `foreach(arg IN LISTS ARGN)` that it just said above that "you will NOT be able to use" `foreach(loop_var IN LISTS ARGN)`:
```
macro(_BAR)
foreach(arg IN LISTS ARGN)
[...]
endforeach()
endmacro()
```
PROBLEM 2:
Also, in the following example, where are the "existing variables"? How would x, y, and z get mapped to "a", "b", and "c". Is there something missing from this example?
```
Note that if you have a variable with the same name in the scope from which the macro is called, using unreferenced names will use the existing variable instead of the arguments. For example:
macro(_BAR)
foreach(arg IN LISTS ARGN)
[...]
endforeach()
endmacro()
function(_FOO)
_bar(x y z)
endfunction()
_foo(a b c)
Will loop over a;b;c and not over x;y;z as one might be expecting. If you want true CMake variables and/or better CMake scope control you should look at the function command.
```https://gitlab.kitware.com/cmake/cmake/-/issues/16211Documentation on default value of CMAKE_INSTALL_PREFIX in Windows is not cor...2018-02-20T16:28:55-05:00Silvio TraversaroDocumentation on default value of CMAKE_INSTALL_PREFIX in Windows is not correctThe documentation of the `CMAKE_INSTALL_PREFIX` variables states that its default value in Windows is `C:/Program Files/` [1], but the default value is actually `C:/Program Files/${PROJECT_NAME}` [2] .
[1] : https://gitlab.kitware....The documentation of the `CMAKE_INSTALL_PREFIX` variables states that its default value in Windows is `C:/Program Files/` [1], but the default value is actually `C:/Program Files/${PROJECT_NAME}` [2] .
[1] : https://gitlab.kitware.com/cmake/cmake/blob/master/Help/variable/CMAKE_INSTALL_PREFIX.rst
[2] : https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmLocalGenerator.cxx#L240 3.7.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/15277Eclipse CDT: CUDA project error parsing broken for Nvidia Nsight2018-02-26T16:37:54-05:00Kitware RobotEclipse CDT: CUDA project error parsing broken for Nvidia NsightThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15277). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15277). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/19087Error in documentation of CTEST_CUSTOM_* variables2022-12-16T08:58:13-05:00Daniel PfeiferError in documentation of CTEST_CUSTOM_* variablesThe documentation of `CTEST_CUSTOM_WARNING_EXCEPTION` reads:
> A list of regular expressions which will be used to exclude when detecting warning messages in build outputs by the `ctest_test()` command.
Shouldn't that be `ctest_build()...The documentation of `CTEST_CUSTOM_WARNING_EXCEPTION` reads:
> A list of regular expressions which will be used to exclude when detecting warning messages in build outputs by the `ctest_test()` command.
Shouldn't that be `ctest_build()`? Same for other `CTEST_CUSTOM_*` variables.https://gitlab.kitware.com/cmake/cmake/-/issues/14700Errors in FILE COPY operations don't report failing cause2017-10-13T13:17:57-04:00Kitware RobotErrors in FILE COPY operations don't report failing causeThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14700). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14700). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17035ExternalProject removes SOURCE_DIR if GIT_URL is set2017-07-21T10:12:36-04:00AlexExternalProject removes SOURCE_DIR if GIT_URL is setThe documentaiton of `ExternalProject_Add` states the following for `SOURCE_DIR`:
> If SOURCE_DIR is explicitly set to an existing directory the project will be built from it. Otherwise a download step must be specified using one of the...The documentaiton of `ExternalProject_Add` states the following for `SOURCE_DIR`:
> If SOURCE_DIR is explicitly set to an existing directory the project will be built from it. Otherwise a download step must be specified using one of the DOWNLOAD_COMMAND, CVS_*, SVN_*, or URL options. The URL option may refer locally to a directory or source tarball, or refer to a remote tarball [...].
It appears that even though the `SOURCE_DIR` exists, it will be **removed** and cloned if `GIT_URL` is set.
- - -
Steps to reproduce:
$ mkdir my_project
$ cd my_project
$ mkdir ext_project
$ touch ext_project/IMPORTANT_FILE
$ vim CMakeLists.txt
$ mkdir build
$ cd build
$ cmake ..
$ make # interrupt as soon as external project has been cloned
$ ls ../ext_project # IMPORTANT_FILE is gone
```cmake
# CMakeLists.txt
cmake_minimum_required(VERSION 3.5)
project(my_project LANGUAGES CXX)
include(ExternalProject)
ExternalProject_Add(
ext_project
GIT_REPOSITORY https://github.com/allscale/allscale_api
SOURCE_DIR ${CMAKE_SOURCE_DIR}/ext_project
)
```
- - -
CMake Version: 3.5.1Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/13949FAIL_REGULAR_EXPRESSION doesn't match beginning-of-line properly2017-10-13T13:18:31-04:00Kitware RobotFAIL_REGULAR_EXPRESSION doesn't match beginning-of-line properlyThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13949). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13949). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/23561Feature request: also add "multiConfig" boolean flag to cmake -E capabilities2022-06-03T10:02:06-04:00AlexFeature request: also add "multiConfig" boolean flag to cmake -E capabilitiesIt would be great if the generator's information from `cmake -E` command will also include the boolean flag describing the "multi-configness" of the reported generator, e.g.:
<details>
<summary>Updated `cmake -E capabilities` JSON answ...It would be great if the generator's information from `cmake -E` command will also include the boolean flag describing the "multi-configness" of the reported generator, e.g.:
<details>
<summary>Updated `cmake -E capabilities` JSON answer (updates marked by '*')</summary>
```
{
"fileApi": {
"requests": [
{
"kind": "codemodel",
"version": [
{
"major": 2,
"minor": *5*
}
]
},
{
"kind": "cache",
"version": [
{
"major": 2,
"minor": 0
}
]
},
{
"kind": "cmakeFiles",
"version": [
{
"major": 1,
"minor": 0
}
]
},
{
"kind": "toolchains",
"version": [
{
"major": 1,
"minor": 0
}
]
}
]
},
"generators": [
{
"extraGenerators": [],
"name": "Watcom WMake",
*"multiConfig" : false*,
"platformSupport": false,
"toolsetSupport": false
},
{
"extraGenerators": [],
"name": "Ninja Multi-Config",
*"multiConfig" : true*,
"platformSupport": false,
"toolsetSupport": false
},
{
"extraGenerators": [
"CodeBlocks",
"CodeLite",
"Eclipse CDT4",
"Kate",
"Sublime Text 2"
],
"name": "Ninja",
*"multiConfig" : false*,
"platformSupport": false,
"toolsetSupport": false
},
{
"extraGenerators": [
"CodeBlocks",
"CodeLite",
"Eclipse CDT4",
"Kate",
"Sublime Text 2"
],
"name": "Unix Makefiles",
*"multiConfig" : false*,
"platformSupport": false,
"toolsetSupport": false
},
{
"extraGenerators": [],
"name": "Green Hills MULTI",
*"multiConfig" : true*,
"platformSupport": true,
"toolsetSupport": true
}
],
"serverMode": false,
"version": {
"isDirty": false,
"major": 3,
"minor": 23,
"patch": 1,
"string": "3.23.1",
"suffix": ""
}
}
```
</details>
This additional information may help e.g. in CI pipelines, where could be cross-platform builds from distinct generators (e.g. ninja and xcode) and if the current generator is multi-config, then the CI would build as `cmake --build <dir> --config Debug` and must not use `CMAKE_BUILD_TYPE` as it would be ignored, and otherwise the CI would build as regular `cmake --build <dir>` and may use `CMAKE_BUILD_TYPE`.
Thanks for your attention.https://gitlab.kitware.com/cmake/cmake/-/issues/15653file(GENERATE): add PERMISSIONS flag2020-12-22T09:12:24-05:00Kitware Robotfile(GENERATE): add PERMISSIONS flagThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15653). Further discussion may take place here.
---
We can set executable permissions with `file(WRITE|COPY)`, but we can't do so wi...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15653). Further discussion may take place here.
---
We can set executable permissions with `file(WRITE|COPY)`, but we can't do so with `file(GENERATE)`. It would be helpful when generating scripts to be able to set the permissions, otherwise we can't use `file(GENERATE)`.
https://gitlab.kitware.com/cmake/cmake/-/issues/8814file(GLOB) needs more specific documentation on supported globbing operations2023-01-11T18:42:43-05:00Kitware Robotfile(GLOB) needs more specific documentation on supported globbing operationsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8814). Further discussion may take place here.
---
In the documentation, there should be specific mention of the globbing expression...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8814). Further discussion may take place here.
---
In the documentation, there should be specific mention of the globbing expressions supported include only `*`, `?`, and `[]`.
Specifically mention that brace expanding (`{}`) isn't supported.
Specifically mention that regular expressions in glob expressions are not supported.
Also, it should provide an example of doing multiple matches in a single expression: `file(GLOB sources "*.cpp" "*.h")`.https://gitlab.kitware.com/cmake/cmake/-/issues/12003find_package fails but reports success with case in sensitive filesystems2018-01-11T09:52:13-05:00Kitware Robotfind_package fails but reports success with case in sensitive filesystemsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12003). Further discussion may take place here.
---
When using `find_package` (i.e. boost) on the mac, you can have a situation wher...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12003). Further discussion may take place here.
---
When using `find_package` (i.e. boost) on the mac, you can have a situation where you use (note the package case):
```cmake
find_package(boost COMPONENTS thread)
```
And do not get a failure, because the `FindBoost.cmake` file has been run, because of the insensitivity of filename reads of the mac filesystem. However, this file expects it's variables to all be set in the form `${Boost_FIND_COMPONENTS}` - but the differently cased `${boost_FIND_COMPONENTS}` are the ones passed through.
The outcome is that the package is incorrectly configured, but no warnings or errors are reported. I would have at least expected a warning, because I can't imagine this behaviour ever being desired.
On Mac, CMakeList.txt:
```cmake
find_package(boost 1.34 COMPONENTS thread )
message("Boost_LIBRARIES: " ${Boost_LIBRARIES})
```
https://gitlab.kitware.com/cmake/cmake/-/issues/16180find_package(Java) does not set Java_INCLUDE_DIRS2018-02-20T16:28:56-05:00Richard Walkerfind_package(Java) does not set Java_INCLUDE_DIRSDocumentation states that the following should be set by calling find_package(Java):
```
# Java_INCLUDE_DIRS - Full paths to all include dirs.
# Java_LIBRARIES - Full paths to all libraries.
```
They...Documentation states that the following should be set by calling find_package(Java):
```
# Java_INCLUDE_DIRS - Full paths to all include dirs.
# Java_LIBRARIES - Full paths to all libraries.
```
They are not. There is no reference to these other than in the comments in FindJava.cmake. Other variables set correctly.
Kind regards,
Richard.3.7.0https://gitlab.kitware.com/cmake/cmake/-/issues/16097FindCUDA.cmake implicit target_link_libraries() can not be mixed with new sig...2017-05-12T17:34:25-04:00Kitware RobotFindCUDA.cmake implicit target_link_libraries() can not be mixed with new signatureThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16097). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16097). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14247FindCxxTest: CXXTEST_ADD_TEST compiles source files in Visual Studio 10 even ...2017-10-13T13:17:57-04:00Kitware RobotFindCxxTest: CXXTEST_ADD_TEST compiles source files in Visual Studio 10 even though they shouldn'tThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14247). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14247). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/7827FindEXPAT finds expat.h in /Library/Frameworks/Mono.framework/Headers instead...2018-04-28T09:16:27-04:00Kitware RobotFindEXPAT finds expat.h in /Library/Frameworks/Mono.framework/Headers instead of /usr/include on Mac OS X.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7827). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7827). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15886FindHTMLHelp.cmake doesn't set HTMLHelp_FOUND variable2017-10-13T13:17:56-04:00Kitware RobotFindHTMLHelp.cmake doesn't set HTMLHelp_FOUND variableThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15886). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15886). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/12626FindJPEG/FindTIFF.cmake do not define _INCLUDE_DIRS variables2019-02-20T14:25:17-05:00Kitware RobotFindJPEG/FindTIFF.cmake do not define _INCLUDE_DIRS variablesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12626). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12626). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17107FindMatlab.cmake command matlab_add_unit_test argument CUSTOM_MATLAB_COMMAND ...2017-07-28T20:07:11-04:00rymutFindMatlab.cmake command matlab_add_unit_test argument CUSTOM_MATLAB_COMMAND not workingDocumentation of `matlab_add_unit_test()` function states that:
> # \`\`CUSTOM_MATLAB_COMMAND\`\`
> # Matlab script command to run as the test.
> # If this is not set, then the following is run:
> # \`\`runtests...Documentation of `matlab_add_unit_test()` function states that:
> # \`\`CUSTOM_MATLAB_COMMAND\`\`
> # Matlab script command to run as the test.
> # If this is not set, then the following is run:
> # \`\`runtests('matlab_file_name'), exit(max([ans(1,:).Failed]))\`\`
> # where \`\`matlab_file_name\`\` is the \`\`UNITTEST_FILE\`\` without the extension.\`
The `CUSTOM_MATLAB_COMMAND` argument is not parsed and used by `matlab_add_unit_test()` function.
Function code uses `CUSTOM_TEST_COMMAND` argument instead of `CUSTOM_MATLAB_COMMAND`.
Documentation entry should be changed to correctly identify argument `CUSTOM_TEST_COMMAND` for setting custom matlab command.Raffi EnficiaudRaffi Enficiaud