CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-08-22T19:50:48-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/18453Provide guidance for install location of config package files2022-08-22T19:50:48-04:00Craig ScottProvide guidance for install location of config package filesDiscussions in !2455 highlighted that the choice of install location for CMake config package files is not obvious. It would be good to provide some guidance to package maintainers for these locations. They would, of course, still be fre...Discussions in !2455 highlighted that the choice of install location for CMake config package files is not obvious. It would be good to provide some guidance to package maintainers for these locations. They would, of course, still be free to make other choices, but if CMake's docs provided a statement along the lines of "in the absence of any other constraints, location BLAH is a suitable choice", I think it would be helpful. I propose that this is probably more a question of updating the documentation rather than augmenting the `GNUInstallDirs` module or providing further functionality elsewhere.
Similar to [@zaufi's comments](https://gitlab.kitware.com/cmake/cmake/merge_requests/2455#note_469969) in !2455, I too see two main cases - packages with or without architecture-dependent contents. I put forward the following reasoning to guide such suggested locations:
## Architecture-dependent Packages
Config files for an architecture-dependent package should go under an architecture-dependent path. This allows systems that support multiple architectures to have packages for multiple architectures installed simultaneously without them interfering with each other. Starting with the set of paths that `find_package()` searches by default, that more or less means putting the files under a path with `lib` or its variants. From there:
* Eliminate any candidates that repeat the package name (DRY principle).
* Eliminate any candidates that are not all lowercase to remove any question of case sensitivity issues across platforms.
* Eliminate any candidates that use `share` in the path because it is less common to see that used under Windows.
* Prefer something with `cmake` in the path so the purpose of the directory contents is clear.
This leaves us with the following candidates from where `find_package()` searches (ignoring the Mac-specific framework and bundle paths, those are covered separately further below):
* `<prefix>/(lib/<arch>|lib*)/cmake/<name>*/` (1)
* `<prefix>/(lib/<arch>|lib*)/<name>*/cmake/` (2)
I'd propose that the docs suggest using `CMAKE_INSTALL_LIBDIR` from `GNUInstallDirs` in place of the `(lib/<arch>|lib*)` part, which just leaves whether to put `cmake` before or after the package name (both choices include the package name in the path, so we have to include it one way or the other). I personally prefer the former (1) because if you have multiple packages being installed, they are nicely collected together under the `cmake` area. It's also the case I've seen more commonly used.
## Architecture-independent Packages
These should not have any architecture-dependent component in their path. If we again prefer to have `cmake` in the path to highlight the purpose of the directory and we also stick with a lowercase `cmake` to avoid case sensitivity issues, we are left with the following candidates:
* `<prefix>/cmake/`
* `<prefix>/<name>*/cmake/`
I suspect most architecture-independent packages don't need much more than the `<packageName>Config.cmake` and perhaps `<packageName>ConfigVersion.cmake` files, since they wouldn't produce any targets that are architecture-specific (potentially only interface targets and/or other things that are not dependent on the build config). This means the need for a package-specific directory is likely to be less compared to architecture-dependent packages (which may have more files for its export sets, etc.). For simplicity, I personally go with the `<prefix>/cmake/` choice, but I can understand a preference for either (it's a pity that there is no `<prefix>/cmake/<name>*/` option, which would have made a consistent pattern between the arch-dependent and arch-independent cases possible and logical). It would be good if anyone with an informed view of whether there is a more prevalent choice for architecture-independent packages could comment on that.
## Apple Bundles And Frameworks
For Apple bundles and frameworks, I believe the likely config package location is much clearer. Having a CMake-specific path is still desirable and frameworks should always prefer a version-specific path if they use versioned frameworks, so there is one clear choice in these cases:
* App bundles --> `<prefix>/<name>.app/Contents/Resources/CMake/`
* Frameworks --> `<prefix>/<name>.framework/Versions/*/Resources/CMake/`
## Discussion
If we can agree on recommended install locations, I propose that we add wording to the `cmake-packages` manual to guide package maintainers and then cross-reference it in the docs for both the `GNUInstallDirs` module and the `find_package()` command.https://gitlab.kitware.com/cmake/cmake/-/issues/23890CMAKE_EXPORT_COMPILE_COMMANDS environment variable isn't supported for all Ma...2022-08-25T08:49:52-04:00Craig ScottCMAKE_EXPORT_COMPILE_COMMANDS environment variable isn't supported for all Makefile generatorsIt seems like the intention was for the `CMAKE_EXPORT_COMPILE_COMMANDS` environment variable to be honoured for all Makefiles generators. This is more or less what the docs for the `CMAKE_EXPORT_COMPILE_COMMANDS` CMake variable state. Ho...It seems like the intention was for the `CMAKE_EXPORT_COMPILE_COMMANDS` environment variable to be honoured for all Makefiles generators. This is more or less what the docs for the `CMAKE_EXPORT_COMPILE_COMMANDS` CMake variable state. However, the implementation in `CMakeGenericSystem.cmake` matches against `Unix Makefiles` rather than just `Makefiles`, so the environment variable is only currently getting picked up for the `Unix Makefiles` generator. I suspect the regular expression should be relaxed to just match `Makefiles`. This would still leave out the "Watcom WMake" generator, but I have no experience with that to know whether exporting the `compile_commands.json` file is supported for that generator.
The documentation for the environment variable should also be updated to make the same statement as the CMake variable regarding which generators support it.https://gitlab.kitware.com/cmake/cmake/-/issues/16427`find_package(Ruby)` returns incorrect paths on macOS2022-08-25T09:53:30-04:00Xu Cheng`find_package(Ruby)` returns incorrect paths on macOS* CMake Version: 3.7.0 (installed by `brew install cmake`)
* OS: macOS Sierra 10.12.1
### Detailed steps to reproduce the problem
* Install Ruby 2.3 by `brew install ruby`.
* Create `CMakeLists.txt` with below content.
```cmake
...* CMake Version: 3.7.0 (installed by `brew install cmake`)
* OS: macOS Sierra 10.12.1
### Detailed steps to reproduce the problem
* Install Ruby 2.3 by `brew install ruby`.
* Create `CMakeLists.txt` with below content.
```cmake
cmake_minimum_required (VERSION 3.7.0)
project(bug)
set(_RUBY_DEBUG_OUTPUT ON)
find_package(Ruby 2.3 REQUIRED)
```
* Run `cmake .`
### What happened
CMake finds Ruby header and libraries, which are all pointed to the system framework (as shown in below log). However, this is incorrect. Because the version of system Ruby is 2.0 instead of 2.3 as required by `CMakeLists.txt`.
```
[snip]
-- --------FindRuby.cmake debug------------
-- _RUBY_POSSIBLE_EXECUTABLE_NAMES: ruby2.3;ruby23;ruby;ruby2.1;ruby21;ruby2.0;ruby20;ruby1.9;ruby19;ruby1.8;ruby18
-- _RUBY_POSSIBLE_LIB_NAMES: ruby;ruby-static;ruby2.3;ruby23;ruby-2.3;ruby-2.3.0
-- RUBY_ARCH_DIR: /usr/local/Cellar/ruby/2.3.1_2/lib/ruby/2.3.0/x86_64-darwin16
-- RUBY_HDR_DIR: /usr/local/Cellar/ruby/2.3.1_2/include/ruby-2.3.0
-- RUBY_POSSIBLE_LIB_DIR: /usr/local/Cellar/ruby/2.3.1_2/lib
-- Found RUBY_VERSION: "2.3.0" , short: "2.3", nodot: "23"
-- _RUBY_REQUIRED_VARS: RUBY_EXECUTABLE;RUBY_INCLUDE_DIR;RUBY_LIBRARY;RUBY_CONFIG_INCLUDE_DIR
-- RUBY_EXECUTABLE: /usr/local/bin/ruby
-- RUBY_LIBRARY: /System/Library/Frameworks/ruby.framework
-- RUBY_INCLUDE_DIR: /System/Library/Frameworks/Ruby.framework/Headers
-- RUBY_CONFIG_INCLUDE_DIR: /System/Library/Frameworks/Ruby.framework/Headers
-- --------------------
-- Found Ruby: /usr/local/bin/ruby (found suitable version "2.3.0", minimum required is "2.3")
[snip]
```
### What should have happened
It should set `RUBY_LIBRARY`, `RUBY_INCLUDE_DIR` and `RUBY_CONFIG_INCLUDE_DIR` to Homebrew Ruby(v2.3) instead of system Ruby(v2.0).
### Cause and Workaround
This is caused as by default CMake has `CMAKE_FIND_FRAMEWORK` as `First` on macOS. In turn, `find_library` and `find_path` inside `FindRuby.cmake` will search macOS Framework before the paths supplied by `HINTS`.
Related Codes which trigger the bug:
* `find_path` in `FindRuby.cmake`: https://github.com/Kitware/CMake/blob/v3.7.0/Modules/FindRuby.cmake#L182-L187
* `find_library` in `FindRuby.cmake`: https://github.com/Kitware/CMake/blob/v3.7.0/Modules/FindRuby.cmake#L238
* Framework path by default has higher priority over `HINTS`: https://github.com/Kitware/CMake/blob/v3.7.0/Source/cmFindPathCommand.cxx#L48-L61
I suspect this bug has wider impact than just Ruby. It may be triggered by other macOS system Framework libraries (e.g. Python). To solve it, I think `HINTS` should have the highest priority, regardless the value of `CMAKE_FIND_FRAMEWORK`.
To workaround it, set `CMAKE_FIND_FRAMEWORK` to `Last` in `CMakeLists.txt`.https://gitlab.kitware.com/cmake/cmake/-/issues/22663Tutorial Improvements2022-08-26T11:54:52-04:00Betsy McPhailTutorial ImprovementsTrack minor issues with Tutorial. Replaces #19371
- [ ] General
- [ ] Suggestion: Change tutorial version for each step
- [ ] Suggestion: Replace `set(CMAKE_CXX_STANDARD 11)` with `target_compile_features`?
- [ ] Step 1
- [...Track minor issues with Tutorial. Replaces #19371
- [ ] General
- [ ] Suggestion: Change tutorial version for each step
- [ ] Suggestion: Replace `set(CMAKE_CXX_STANDARD 11)` with `target_compile_features`?
- [ ] Step 1
- [ ] Explicitly mention why we're setting cmake_minimum_required VERSION to 3.10. Some folks think this means the tutorial is out of date ([discussion](https://gitlab.kitware.com/cmake/cmake/-/commit/ba09ff7810644f3b7a16088f842213b9f1e03f50))
- [x] Add a note early in Step1: "you can build and run this now!" Demonstrates how simple a CMake project can be. Also a good confidence booster to keep people interested in completing the tutorial. !6576
- [x] Step 2
- [x] We've noticed multiple users struggle with Step2 by calling `add_subdirectory(MathFunctions)` twice. Try to improve the instructions to make this part less error-prone. !6559
- [ ] Step 4 !6564
- [ ] Update `install` command in this step and subsequent ones to use the default locations provided by GNUInstallDirs.
- [ ] Change `endfunction(do_test)` to `endfunction()`
- [ ] Mention release mode is required for Visual Studio
- [ ] Some users get confused where they're supposed to run the tests from: binary tree vs. install tree. Update the language here to consistently use the term "binary directory" rather than "build directory"?
- [x] Step 5
- [x] Clarify instructions on where the first code block should be added in your CMakeLists.txt file. !6577
- [x] Step 8
- [x] Having to write your own `CTestConfig.cmake` file by hand isn't something we do "in real life". Provide a prewritten copy of this file and update the text to explain what it is and where it comes from (CDash). !6565
- [ ] Step 9
- [ ] The expected linker error does not occur on Mac. Either change the example so it does, or add a note to the directions mentioning that this is the expected behavior.
- [ ] Describe where the namespace is introduced in the source
- [ ] Describe MathFunctions.cxx (it just appears?)
- [ ] Step 10
- [ ] Bump minimum required version to v3.15 when the COMPILE_LANG_AND_ID genex was introduced. Make sure this is mentioned in the instructions.
- [ ] `installable_libs` should not include `tutorial_compile_flags` ?
- [ ] Add a warning or error that would indicate it’s working as expected (e.g. add unused variable to MathFunctions.cxx). Also, the "Exercise" is needed to finish the Step. It should be moved to part of the instructions. See
#22702
- [ ] Step 11 !6575
- [ ] Add text to describe `configure_package_config_file` and `write_basic_package_version_file`.
- [ ] Update text : The EXPORT keyword generates ~and installs~Betsy McPhailBetsy McPhailhttps://gitlab.kitware.com/cmake/cmake/-/issues/21765MSVC Debug option set differs from original IDE defaults2022-08-26T23:06:40-04:00Serg KryvonosMSVC Debug option set differs from original IDE defaults****Visual C++ projects debug configuration is not fully supported at this moment.
When we create project with Visual Studio, the generated project has different compile and link options set.
As result important MSVC debugging function...****Visual C++ projects debug configuration is not fully supported at this moment.
When we create project with Visual Studio, the generated project has different compile and link options set.
As result important MSVC debugging functionality isn’t working for projects generated with CMake MSVC generators.
STR:
- Generate debug configuration for MSVC (any version)
- open in Visual Studio
- Set a breakpoint
- Run debug
- Add new line after breakpoint
- continue executing
Expected:
- as in Visual Studio execution continues
Actual:
- error message appears
Please, consider this fix: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5755https://gitlab.kitware.com/cmake/cmake/-/issues/20256Separate debug information2022-08-26T23:06:41-04:00Cristian AdamSeparate debug informationIf I build an application with `RelWithDebInfo` build type I will get a release with debug information build.
Now if I want to distribute the application I don't want to ship the debug information, since it tends to be big. But make it ...If I build an application with `RelWithDebInfo` build type I will get a release with debug information build.
Now if I want to distribute the application I don't want to ship the debug information, since it tends to be big. But make it available in the situation that my application crashes so that the call stack makes sense.
CMake offers in `CPackDeb.cmake` the ability to have files generated by `objcopy --only-keep-debug` calls.
Unfortunately there is nothing about `dsymutil` for macOS.
Users have done the following for macOS:
```cmake
find_program(DSYMUTIL_PROGRAM dsymutil)
if (DSYMUTIL_PROGRAM)
foreach(lang C CXX)
foreach(var LINK_EXECUTABLE CREATE_SHARED_LIBRARY)
set(CMAKE_${lang}_${var} "${CMAKE_${lang}_${var}}" "${DSYMUTIL_PROGRAM} <TARGET>")
endforeach()
endforeach()
endif()
```
I was thinking at having a per target property `SEPARATE_DEBUG_INFO` initialized by `CMAKE_SEPARATE_DEBUG_INFO` which would call `objcopy --only-keep-debug` for GNU, `dsymutil` for macOS/Clang.
Then when the user issues an `install(TARGET)` add the above generated debug file to a component named `DebugInfo`.
Then when the user does a `cmake --install . --component DebugInfo` the debug files will be installed. This would include the MSVC's PDB files.
Then one just has to pack / archive the directory and it's not specific only to a CPack format.https://gitlab.kitware.com/cmake/cmake/-/issues/19676Swift applications are not debuggable by default2022-08-26T23:06:41-04:00Stephen H. GerstackerSwift applications are not debuggable by defaultI created a simple macOS application with the default storyboard and view controller. Setting breakpoints did not work at all in Swift. The project had a separate C-based library, and breakpoints worked within C files. I had to add the t...I created a simple macOS application with the default storyboard and view controller. Setting breakpoints did not work at all in Swift. The project had a separate C-based library, and breakpoints worked within C files. I had to add the target properties to make breakpoints work. I tried to keep these settings as close to a stock Xcode project as possible.
XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH[variant=Debug] "YES"
XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT "dwarf-with-dsym"
XCODE_ATTRIBUTE_DEBUG_INFORMATION_FORMAT[variant=Debug] "dwarf"
XCODE_ATTRIBUTE_ENABLE_TESTIBILITY[variant=Debug] "YES"
XCODE_ATTRIBUTE_GCC_GENERATE_DEBUGGING_SYMBOLS "YES"
XCODE_ATTRIBUTE_GCC_OPTIMIZATION_LEVEL "s"
XCODE_ATTRIBUTE_GCC_OPTIMIZATION_LEVEL[variant=Debug] "0"
XCODE_ATTRIBUTE_GCC_SYMBOLS_PRIVATE_EXTERN "NO"
XCODE_ATTRIBUTE_CLANG_ENABLE_MODULES YES
XCODE_ATTRIBUTE_SWIFT_OPTIMIZATION_LEVEL "-Owholemodule"
XCODE_ATTRIBUTE_SWIFT_OPTIMIZATION_LEVEL[variant=Debug] "-Onone"https://gitlab.kitware.com/cmake/cmake/-/issues/22561CMAKE_SKIP_INSTALL_RULES has very noisy warning behavior2022-08-29T12:00:06-04:00Alex Reinkingareinkin@qti.qualcomm.comCMAKE_SKIP_INSTALL_RULES has very noisy warning behaviorConsider the following CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.21)
project(test NONE)
install(FILES "foo.txt" DESTINATION "share")
```
If I run `cmake -S . -B build -DCMAKE_SKIP_INSTALL_RULES=YES`, I get a warning... why?...Consider the following CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.21)
project(test NONE)
install(FILES "foo.txt" DESTINATION "share")
```
If I run `cmake -S . -B build -DCMAKE_SKIP_INSTALL_RULES=YES`, I get a warning... why?
```
$ cmake -S . -B build -DCMAKE_SKIP_INSTALL_RULES=YES
CMake Warning in CMakeLists.txt:
CMAKE_SKIP_INSTALL_RULES was enabled even though installation rules have
been specified
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build
```
This looks to me like the warning reports simply that the feature works as intended. Are we all *really* supposed to guard our install rules with a check for this variable?
```
if (NOT CMAKE_SKIP_INSTALL_RULES)
install(...)
endif ()
```
I would think the variable should simply disable the `install()` command (as if it were not written in the first place)... after all, that's what the [documentation suggests](https://cmake.org/cmake/help/latest/variable/CMAKE_SKIP_INSTALL_RULES.html).
> Whether to disable generation of installation rules.
>
> If `TRUE`, CMake will neither generate installation rules nor will it generate `cmake_install.cmake` files. This variable is `FALSE` by default.
As reported in #17694, this also misleads readers into thinking that it could work on a per-directory basis. But given the warning, I am confused by the feature as a global flag. If I'm expected to manually guard my `install()` rules, then what is the point?https://gitlab.kitware.com/cmake/cmake/-/issues/20446CMakeFindFrameworks module should be deprecated2022-08-29T18:12:56-04:00Bo AndersonCMakeFindFrameworks module should be deprecatedIts `CMAKE_FIND_FRAMEWORKS` macro does not search `CMAKE_FRAMEWORK_PATH` (or offer similar alternative flexibility).
Currently `CMAKE_FIND_FRAMEWORKS` contains a fixed list of framework locations:
https://gitlab.kitware.com/cmake/cmake...Its `CMAKE_FIND_FRAMEWORKS` macro does not search `CMAKE_FRAMEWORK_PATH` (or offer similar alternative flexibility).
Currently `CMAKE_FIND_FRAMEWORKS` contains a fixed list of framework locations:
https://gitlab.kitware.com/cmake/cmake/-/blob/c06e0356017beef41cd2bb57a6cebfb242a9128e/Modules/CMakeFindFrameworks.cmake#L21-25
However, it's possible, in particular for package managers, that additional items may want to be inserted to this list. This is already possible in other places via `CMAKE_FRAMEWORK_PATH`, but not in `CMAKE_FIND_FRAMEWORKS`.
The current `CMAKE_FIND_FRAMEWORK_EXTRA_LOCATIONS` is too limited. Instead of acting as a base frameworks directory that CMake can search for `${fwk}.framework` in, it only works when supplied with the full path for a specific framework, which could actually end up being used even if that framework might not even be for `fwk`.https://gitlab.kitware.com/cmake/cmake/-/issues/23902FindJava ignores JAVA_HINT for binaries2022-08-30T05:11:42-04:00Tobias C. BernerFindJava ignores JAVA_HINT for binariesMoin moin
FindJava.cmake fails to properly find the java executable when one specifies a JAVA_HOME, but has another java in $PATH.
Minimal CMakeLists.txt:
```
cmake_minimum_required (VERSION 3.23.0)
project(FindJava-bug)
set(JAVA_HO...Moin moin
FindJava.cmake fails to properly find the java executable when one specifies a JAVA_HOME, but has another java in $PATH.
Minimal CMakeLists.txt:
```
cmake_minimum_required (VERSION 3.23.0)
project(FindJava-bug)
set(JAVA_HOME "/usr/local/openjdk17")
find_package(Java 17 REQUIRED COMPONENTS Runtime)
message("Found java: ${Java_FOUND}")
message("Java: ${Java_JAVA_EXECUTABLE}")
```
Output:
```
-- Found Java: /usr/local/bin/java (found suitable version "17.0.4", minimum required is "17") found components: Runtime
Found java: TRUE
Java: /usr/local/bin/java
```
In $PATH there is `/usr/local/bin/java` with version `1.8.0_342`.
The value of Java_JAVA_EXECUTABLE should be the one pointing to the JAVA_HOME which it also correctly identified in the first part of the find call, i.e. `/usr/local/openjdk17/bin/java`.https://gitlab.kitware.com/cmake/cmake/-/issues/23796Find_matlab fails with cannot find Matlab_MEX_LIBRARY Matlab_MEX_EXTENSION an...2022-08-30T05:24:33-04:00Maitrey MishraFind_matlab fails with cannot find Matlab_MEX_LIBRARY Matlab_MEX_EXTENSION and Matlab_MX_LIBRARYHello CMake Folks,
I am using cmake-3.21.1 and matlab 9.5(64 bit), Windows and mingw64 as makefile generator.
I am not using anything else but using find_matlb to get the location of matlab.exe.
find_package(Matlab 9.5 OPTIONAL_COMPONE...Hello CMake Folks,
I am using cmake-3.21.1 and matlab 9.5(64 bit), Windows and mingw64 as makefile generator.
I am not using anything else but using find_matlb to get the location of matlab.exe.
find_package(Matlab 9.5 OPTIONAL_COMPONENTS MEX_COMPILER ENG_LIBRARY MCC_COMPILER SIMULINK)
if (MATLAB_FOUND)
message("Do something")
else
message("Do nothing")
endif()
But find_matlab cannot find Matlab_MEX_LIBRARY Matlab_MEX_EXTENSION and Matlab_MX_LIBRARY
I added
SET(CMAKE_FIND_DEBUG_MODE ON)
set(MATLAB_FIND_DEBUG TRUE)
and noticed the following :
-- [MATLAB] Matlab root folders are MATLAB;9.5;C:/Program Files/MATLAB/R2018b
-- [MATLAB] Current version is 9.5 located C:/Program Files/MATLAB/R2018b
CMake Debug Log at C:/Program Files/CMake/share/cmake-3.21/Modules/FindMatlab.cmake:611 (find_program):
find_program called with the following settings:
VAR: Matlab_MEXEXTENSIONS_PROG
NAMES: "mexext"
Documentation: Matlab MEX extension provider
Framework
Only Search Frameworks: 0
Search Frameworks Last: 0
Search Frameworks First: 0
AppBundle
Only Search AppBundle: 0
Search AppBundle Last: 0
Search AppBundle First: 0
NO_DEFAULT_PATH Enabled
find_program considered the following locations:
C:/Program Files/MATLAB/R2018b/bin/mexext.com
C:/Program Files/MATLAB/R2018b/bin/mexext.exe
C:/Program Files/MATLAB/R2018b/bin/mexext
The item was not found.
CMake Debug Log at C:/Program Files/CMake/share/cmake-3.21/Modules/FindMatlab.cmake:1692 (find_library):
find_library called with the following settings:
VAR: Matlab_MEX_LIBRARY
NAMES: "mex"
Documentation: Path to a library.
Framework
Only Search Frameworks: 0
Search Frameworks Last: 0
Search Frameworks First: 0
AppBundle
Only Search AppBundle: 0
Search AppBundle Last: 0
Search AppBundle First: 0
NO_DEFAULT_PATH Enabled
find_library considered the following locations:
C:/Program Files/MATLAB/R2018b/bin/win64/(lib|lib)mex(\.so|\.a)
C:/Program Files/MATLAB/R2018b/extern/bin/win64/(lib|lib)mex(\.so|\.a)
The item was not found.
I am wondering why is it looking for .so or .a while it should look for .dll.
Could someone please help me?https://gitlab.kitware.com/cmake/cmake/-/issues/23846Example from cmake-generator-expressions is not robust2022-08-30T07:05:29-04:00StefanBruensExample from cmake-generator-expressions is not robustFrom https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#whitespace-and-quoting
```
# The $<BOOL:...> check prevents adding anything if the property is empty,
# assuming the property value cannot be one of CMak...From https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#whitespace-and-quoting
```
# The $<BOOL:...> check prevents adding anything if the property is empty,
# assuming the property value cannot be one of CMake's false constants.
set(prop "$<TARGET_PROPERTY:tgt,INCLUDE_DIRECTORIES>")
add_custom_target(run_some_tool
COMMAND some_tool "$<$<BOOL:${prop}>:-I$<JOIN:${prop},;-I>>"
COMMAND_EXPAND_LISTS
VERBATIM
)
```
Unfortunately, this is not robust. A trivial example is `set(prop ";")`, which is evaluated to true by the `BOOL` check.
A less artificial example which fails this check are apparently generator expressions. The latest nlohman_json has the following COMPILE_DEFINITIONS:
```
INTERFACE_COMPILE_DEFINITIONS "\$<\$<NOT:\$<BOOL:ON>>:JSON_USE_GLOBAL_UDLS=0>;\$<\$<NOT:\$<BOOL:ON>>:JSON_USE_IMPLICIT_CONVERSIONS=0>;\$<\$<BOOL:OFF>:JSON_DISABLE_ENUM_SERIALIZATION=1>;\$<\$<BOOL:OFF>:JSON_DIAGNOSTICS=1>;\$<\$<BOOL:OFF>:JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON=1>"
```
This may expand to `;;;;;`, which is expanded to `-D` with the code from the example.
Changing `$<BOOL:${prop}>:...` to `$<BOOL:$<JOIN:${prop},;>>:...` avoids this error.
```
set(prop ";")
add_custom_target(genexdebug}
COMMAND ${CMAKE_COMMAND} -E echo "T_Err: $<$<BOOL:${prop}>:-I$<JOIN:${prop},;-I>>"
COMMAND ${CMAKE_COMMAND} -E echo "T_OK: $<$<BOOL:$<JOIN:${prop},;>>:-I$<JOIN:${prop},;-I>>"
COMMAND_EXPAND_LISTS
VERBATIM
)
```
I think https://gitlab.kitware.com/cmake/cmake/-/issues/20951 was meant to fix this, but there are obviously cases which are not handled correctly (CMake 3.24.0).https://gitlab.kitware.com/cmake/cmake/-/issues/23874FindMPI and FindOpenMP do not work with CMAKE_EXECUTABLE_SUFFIX2022-08-30T16:11:28-04:00Jakub KlinkovskýFindMPI and FindOpenMP do not work with CMAKE_EXECUTABLE_SUFFIXMinimal reproducible example:
```
cmake_minimum_required(VERSION 3.24.1)
project(foo)
set(CMAKE_EXECUTABLE_SUFFIX "-dbg${CMAKE_EXECUTABLE_SUFFIX}")
find_package(MPI)
find_package(OpenMP)
```
Output of `cmake -B build -S .`:
```
CMake Err...Minimal reproducible example:
```
cmake_minimum_required(VERSION 3.24.1)
project(foo)
set(CMAKE_EXECUTABLE_SUFFIX "-dbg${CMAKE_EXECUTABLE_SUFFIX}")
find_package(MPI)
find_package(OpenMP)
```
Output of `cmake -B build -S .`:
```
CMake Error at /usr/share/cmake/Modules/FindMPI.cmake:1269 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindMPI/test_mpi_C.bin'
Unable to find the executable at any of:
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/cmTC_b22c0-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Debug/cmTC_b22c0-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Development/cmTC_b22c0-dbg
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindMPI.cmake:1320 (_MPI_try_staged_settings)
/usr/share/cmake/Modules/FindMPI.cmake:1643 (_MPI_check_lang_works)
CMakeLists.txt:4 (find_package)
CMake Error at /usr/share/cmake/Modules/FindMPI.cmake:1746 (file):
file STRINGS file
"/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindMPI/test_mpi_C.bin"
cannot be read.
Call Stack (most recent call first):
CMakeLists.txt:4 (find_package)
CMake Error at /usr/share/cmake/Modules/FindMPI.cmake:1269 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindMPI/test_mpi_CXX.bin'
Unable to find the executable at any of:
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/cmTC_b9e51-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Debug/cmTC_b9e51-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Development/cmTC_b9e51-dbg
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindMPI.cmake:1320 (_MPI_try_staged_settings)
/usr/share/cmake/Modules/FindMPI.cmake:1643 (_MPI_check_lang_works)
CMakeLists.txt:4 (find_package)
CMake Error at /usr/share/cmake/Modules/FindMPI.cmake:1269 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindMPI/test_mpi_CXX.bin'
Unable to find the executable at any of:
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/cmTC_e08a5-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Debug/cmTC_e08a5-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Development/cmTC_e08a5-dbg
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindMPI.cmake:1670 (_MPI_try_staged_settings)
CMakeLists.txt:4 (find_package)
CMake Error at /usr/share/cmake/Modules/FindMPI.cmake:1746 (file):
file STRINGS file
"/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindMPI/test_mpi_CXX.bin"
cannot be read.
Call Stack (most recent call first):
CMakeLists.txt:4 (find_package)
CMake Error at /usr/share/cmake/Modules/FindOpenMP.cmake:397 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindOpenMP/ompver_C.bin'
Unable to find the executable at any of:
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/cmTC_82cd4-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Debug/cmTC_82cd4-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Development/cmTC_82cd4-dbg
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindOpenMP.cmake:525 (_OPENMP_GET_SPEC_DATE)
CMakeLists.txt:5 (find_package)
CMake Error at /usr/share/cmake/Modules/FindOpenMP.cmake:397 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/FindOpenMP/ompver_CXX.bin'
Unable to find the executable at any of:
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/cmTC_e7462-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Debug/cmTC_e7462-dbg
/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeTmp/Development/cmTC_e7462-dbg
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindOpenMP.cmake:525 (_OPENMP_GET_SPEC_DATE)
CMakeLists.txt:5 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/lahwaacz/stuff/cmake_bug_CMAKE_EXECUTABLE_SUFFIX/build/CMakeFiles/CMakeOutput.log".
```https://gitlab.kitware.com/cmake/cmake/-/issues/23875CPack/DEB: Add Build-Depends field to control file2022-08-30T16:12:17-04:00danial khalajCPack/DEB: Add Build-Depends field to control fileIs there any way to add Build-Depends to control file with Cpack?
Build-Depends link:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydepsIs there any way to add Build-Depends to control file with Cpack?
Build-Depends link:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydepshttps://gitlab.kitware.com/cmake/cmake/-/issues/19204Request: Option to force `file(COPY` to overwrite despite identical time step2022-08-30T16:15:14-04:00Joel A. KuleszaRequest: Option to force `file(COPY` to overwrite despite identical time stepIn the `file(COPY` documentation [here](https://cmake.org/cmake/help/latest/command/file.html#copy), it is noted that:
> Copying preserves input file timestamps, and **optimizes out a file if it exists at the destination with the same t...In the `file(COPY` documentation [here](https://cmake.org/cmake/help/latest/command/file.html#copy), it is noted that:
> Copying preserves input file timestamps, and **optimizes out a file if it exists at the destination with the same timestamp.**
Can an option be introduced to override this "optimization" and force copying (with overwriting) a file where the timestamps appear to be identical?https://gitlab.kitware.com/cmake/cmake/-/issues/20740ODR violation in cm{CommandArgument,Fortran}Lexer.cxx2022-08-30T17:00:50-04:00Дилян ПалаузовODR violation in cm{CommandArgument,Fortran}Lexer.cxxCompiling cmake 1.17.2 with gcc 9.3.1 20200506 and linking with ld.bfd 2.34.50.20200519 prints:
```
[2/46] Linking CXX executable bin/cmake
../Source/LexerParser/cmFortranLexer.cxx:869:8: warning: type ‘struct yyguts_t’ violates the C++ ...Compiling cmake 1.17.2 with gcc 9.3.1 20200506 and linking with ld.bfd 2.34.50.20200519 prints:
```
[2/46] Linking CXX executable bin/cmake
../Source/LexerParser/cmFortranLexer.cxx:869:8: warning: type ‘struct yyguts_t’ violates the C++ One Definition Rule [-Wodr]
869 | struct yyguts_t
| ^
../Source/LexerParser/cmCommandArgumentLexer.cxx:697:8: note: a different type is defined in another translation unit
697 | struct yyguts_t
| ^
../Source/LexerParser/cmFortranLexer.cxx:873:19: note: the first difference of corresponding definitions is field ‘yyextra_r’
873 | YY_EXTRA_TYPE yyextra_r;
| ^
../Source/LexerParser/cmCommandArgumentLexer.cxx:701:19: note: a field of same name but different type is defined in another translation unit
701 | YY_EXTRA_TYPE yyextra_r;
| ^
../Source/LexerParser/cmFortranLexer.cxx:869:8: note: type name ‘cmFortranParser_s’ should match type name ‘cmCommandArgumentParserHelper’
869 | struct yyguts_t
| ^
../Source/cmCommandArgumentParserHelper.h:13:7: note: the incompatible type is defined here
13 | class cmCommandArgumentParserHelper
| ^
```
I use flex 2.6.4 (released 2017)https://gitlab.kitware.com/cmake/cmake/-/issues/23877gitlab-ci: consider using ccache instead of sccache2022-08-30T17:47:32-04:00Cristian Adamgitlab-ci: consider using ccache instead of sccache[ccache](https://github.com/ccache/ccache) is a compiler cache tool written (nowadays) in C++ and uses CMake as build system. Just like CMake itself.
It supports having redis as a remote backed, and since version 4.6 also Visual C++.
I...[ccache](https://github.com/ccache/ccache) is a compiler cache tool written (nowadays) in C++ and uses CMake as build system. Just like CMake itself.
It supports having redis as a remote backed, and since version 4.6 also Visual C++.
I think the C++ community would benefit if the two projects would use each other's product and potential fixes that would result from this usage.https://gitlab.kitware.com/cmake/cmake/-/issues/23893install(EXPORT): Should the integrity check really be fatal?2022-08-31T03:23:48-04:00Bernhard Rosenkränzerinstall(EXPORT): Should the integrity check really be fatal?Should the integrity check in cmExportFileGenerator::GenerateImportedFileCheckLoop really be fatal?
https://gitlab.kitware.com/cmake/cmake/-/blob/60a1ccbd6a913d09d7c0a3f2b104e60699718e07/Source/cmExportFileGenerator.cxx#L1197 produces a...Should the integrity check in cmExportFileGenerator::GenerateImportedFileCheckLoop really be fatal?
https://gitlab.kitware.com/cmake/cmake/-/blob/60a1ccbd6a913d09d7c0a3f2b104e60699718e07/Source/cmExportFileGenerator.cxx#L1197 produces a FATAL_ERROR if a file that got installed alongside the cmake exports file is not installed on the system.
While this can be useful, it is often a non-issue: For example, in Qt 6, this triggers a fatal error if any of the optional widget style plugins [that nothing could link to at build time even if it wanted to] have been removed.
Or, in LLVM, it triggers a fatal error if MLIR is not installed when something just uses cmake to check for libLLVM.
Of course a possible answer to this is "don't build the bits you don't need then" -- but in the case of distribution packages, this is not always possible (e.g. we certainly want to have all the Qt styles available to our users, but we don't want to force anyone using cmake to link against QtGui to install the GTK style plugin which pulls in hundreds of megabytes of dependencies).
For those use cases, it would be preferable to downgrade that FATAL_ERROR to a WARNING - if afterwards, everything succeeds, it's clear that the installation is just "missing" an optional and useless in the context file, but if something fails, the user will still have seen the warning and knows what file he may need to look for.https://gitlab.kitware.com/cmake/cmake/-/issues/20907CPack WIX setting CPACK_WIX_ROOT_FOLDER_ID with something that is not Program...2022-08-31T05:04:16-04:00b1u3dr4g0nf1yCPack WIX setting CPACK_WIX_ROOT_FOLDER_ID with something that is not ProgramFiles or CommonFiles fails. Missing GUID.Hello everyone,
We want to install our App, in say D:/MyFolder. But when setting `CPACK_WIX_ROOT_FOLDER_ID` to MyFolder fails in WIX, because the generated XML needs to have a ComponentGuidGenerationSeed attribute. (See [Wix docs](htt...Hello everyone,
We want to install our App, in say D:/MyFolder. But when setting `CPACK_WIX_ROOT_FOLDER_ID` to MyFolder fails in WIX, because the generated XML needs to have a ComponentGuidGenerationSeed attribute. (See [Wix docs](https://wixtoolset.org/documentation/manual/v3/xsd/wix/directory.html))
This seems to be a fairly common use case tough.
I also tried to Patch MyFolder element, but without success, should I file a separate bug or is it aswell unsuported ?
```xml
<CPackWiXPatch>
<CPackWiXFragment Id="MyFolder" ComponentGuidGenerationSeed="20605832-28BD-4D78-B40D-8B53F2F20DA6">
</CPackWiXFragment>
</CPackWiXPatch>
```
What's the way to achieve this, if it's possible ?
Thanks you for you time.https://gitlab.kitware.com/cmake/cmake/-/issues/22445CMake does not pass -isystem paths to cppcheck2022-09-01T09:51:34-04:00languagelawyerCMake does not pass -isystem paths to cppcheckAs a result, if `cppcheck` is asked to use Clang for parsing, Clang won't be able to find the headers from `-isystem` paths.
```sh
$ /path/to/cmake -E __run_co_compile --cppcheck="/path/to/cppcheck;--clang=/path/to/clang" --source=projec...As a result, if `cppcheck` is asked to use Clang for parsing, Clang won't be able to find the headers from `-isystem` paths.
```sh
$ /path/to/cmake -E __run_co_compile --cppcheck="/path/to/cppcheck;--clang=/path/to/clang" --source=project/source.cxx -- /path/to/compiler -DSOME_DEFINITION -Iproject/include/ -isystem /dependency/include/ -std=c++17 -o ... -c ...
```
will invoke `cppcheck` only with `--clang=/path/to/clang -DSOME_DEFINITION -Iproject/include/ project/source.cxx` (there is even no `--std=c++17`!) and `cppcheck` will invoke `clang` as
```
/path/to/clang -fsyntax-only -Xclang -ast-dump -fno-color-diagnostics -x c++ -Iproject/include/ -DSOME_DEFINITION project/source.cxx
```
which will fail to find include files from `/dependency/include/`
(BTW [`cppcheck` cmdline parser](https://github.com/danmar/cppcheck/blob/d46750569607495916d8f4ba3585affd6ae48691/cli/cmdlineparser.cpp#L118) doesn't seem to handle `-isystem`)