CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-11-12T05:27:41-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/15234[Feature Request] Allow interface library have public header source2019-11-12T05:27:41-05:00Kitware Robot[Feature Request] Allow interface library have public header sourceThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15234). Further discussion may take place here.
---
By allowing this. The public header installation needn't to be manually specifie...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15234). Further discussion may take place here.
---
By allowing this. The public header installation needn't to be manually specified by INSTALL(FILES ...). And this make it more friendly for IDE to cooperating with CMake.
https://gitlab.kitware.com/cmake/cmake/-/issues/16521Add iOS cross-compiling documentation to the cmake-toolchains guide2019-08-01T19:41:21-04:00Jérémie DelaitreAdd iOS cross-compiling documentation to the cmake-toolchains guideHi,
The cross-compilation guide at https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling is getting better and better, but it still misses instructions to build for iOS (e.g. iphone and iphone simulator).
I...Hi,
The cross-compilation guide at https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling is getting better and better, but it still misses instructions to build for iOS (e.g. iphone and iphone simulator).
I guess most people will use the Xcode generator when building for those targets so specific instructions for this generator might be a nice addition as well.
Most of what I can find on the Internet recommend using the toolchain file https://github.com/cristeab/ios-cmake but it does feel a bit of a hack (it is trying to force the compiler to gcc, which does not work and is deprecated, it by passes the compiler checks...).
I also found good information in the following thread: https://cmake.org/pipermail/cmake-developers/2015-December/027260.html
Basically, it would be nice to have an official CMake guide when targetting iOS. A support as good as the brand new Android work would be awesome!https://gitlab.kitware.com/cmake/cmake/-/issues/22550XCode new build system: Clean always fails with subdirectory2023-02-10T11:14:56-05:00Daniel EvansXCode new build system: Clean always fails with subdirectoryThis is an issue when using the new build system in XCode 12 and 13. Any non-trivial project fails to clean after building, as the new build system will refuse to delete a folder in the build tree.
Tested in CMake 3.19 and CMake 3.21.1
...This is an issue when using the new build system in XCode 12 and 13. Any non-trivial project fails to clean after building, as the new build system will refuse to delete a folder in the build tree.
Tested in CMake 3.19 and CMake 3.21.1
```
$ cmake --build . --target clean
Command line invocation:
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -project clean_test.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
User defaults from command line:
HideShellScriptEnvironment = YES
note: Using new build system
note: Building targets in parallel
warning: Refusing to delete `/tmp/Code/cmake/clean_test/build` because it contains one of the projects in this workspace: `/tmp/Code/cmake/clean_test/build/clean_test.xcodeproj`.
error: Could not delete `/tmp/Code/cmake/clean_test/build/test_app` because it was not created by the build system.
warning: Refusing to delete `/tmp/Code/cmake/clean_test/build` because it contains one of the projects in this workspace: `/tmp/Code/cmake/clean_test/build/clean_test.xcodeproj`.
** CLEAN FAILED **
```
Project that reproduces the issue: [clean_test.zip](/uploads/95c6b7f301b15840d7eacb45dd05705f/clean_test.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/16136cmake --build can not build several targets2019-03-13T10:38:23-04:00Kitware Robotcmake --build can not build several targetsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16136). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16136). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/16482MSVC standard version switches2018-03-31T07:42:05-04:00Nils GladitzMSVC standard version switchesVisual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest`...Visual Studio C++ 2015 Update 3 introduced standard version switches [1].
They seem to only make sense for >= C++14 which I assume becomes relevant with the changes in !299 (#16468).
Specifically for C++17 features `/std:c++latest` (and later `/std:c++17`) might be required.
<br/>
[1] https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/3.10.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16291Detect GCC system include paths at run-time and automatically add them to CMA...2023-08-22T17:31:43-04:00Carlos Alberto Lopez PerezDetect GCC system include paths at run-time and automatically add them to CMAKE_${LANG}_IMPLICIT_INCLUDE_DIRECTORIESHi,
GCC 6 has introduced a change that broke some C++ projects when the project uses system includes (-isystem) via passing the parameter SYSTEM to CMake's functions include_directories or target_include_directories.
This didn't broke ...Hi,
GCC 6 has introduced a change that broke some C++ projects when the project uses system includes (-isystem) via passing the parameter SYSTEM to CMake's functions include_directories or target_include_directories.
This didn't broke the 99% of the standard builds because CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES and CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES already default to /usr/include. So CMake automatically filters /usr/include from the list of includes when calling the compiler.
But when cross-compiling or when using a non-default system include directory, the build breaks.
On the WebKit project we work-around'ed this by calling GCC at run-time to obtain the list of system includes, to automatically add this directories to the above variables.
Perhaps it makes sense to introduce this change in CMake itself, as I think it may be useful for everybody. It is also probably a good idea to avoid passing -I/-isystem for directories that the compiler already assumes as default include directories. It keeps thinga cleaner and simple.
* The change we did is this one: https://trac.webkit.org/changeset/205672/trunk/Source/cmake/OptionsCommon.cmake
* And here is the WebKit bug that contains details about this issue: https://bugs.webkit.org/show_bug.cgi?id=161697
* The GCC bug report itself that got closed as wontfix is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129https://gitlab.kitware.com/cmake/cmake/-/issues/15826target_compile_options de-duplicates flags but some repeats matter2023-06-02T05:51:40-04:00Kitware Robottarget_compile_options de-duplicates flags but some repeats matterThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15826). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15826). Further discussion may take place here.3.12.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20564cmake --build: --parallel when used with msbuild does not enable parallelism ...2022-12-22T12:42:44-05:00Richard von Lehecmake --build: --parallel when used with msbuild does not enable parallelism within a projectWhen I use the --parallel option with a visual studio generator, it enables msbuild parallelism (build multiple *projects* at the same time), but not single-project parallelism. It explicitly prevents the latter by setting CL_MPcount=1....When I use the --parallel option with a visual studio generator, it enables msbuild parallelism (build multiple *projects* at the same time), but not single-project parallelism. It explicitly prevents the latter by setting CL_MPcount=1. I feel it would be more similar to other platforms to instead have --parallel change CL_MPcount and leave /m at 1.
Some discussion around this is captured here:
https://discourse.cmake.org/t/parallel-does-not-really-enable-parallel-compiles-with-msbuild/964/103.26.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/15448find_path() after mark_as_advanced()2020-02-09T23:40:56-05:00Kitware Robotfind_path() after mark_as_advanced()This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15448). Further discussion may take place here.
---
It not clear to me if the following is a bug in CMake or just an invalid use...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15448). Further discussion may take place here.
---
It not clear to me if the following is a bug in CMake or just an invalid use:
(I tested this for CMake 2.8.11, 3.0.1 and 3.2.1.)
```cmake
set(my_path "anyvalue")
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
mark_as_advanced(my_path)
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
message("my_path: '${my_path}'") # my_path is empty here!
```
1st `FIND_PATH()` uses only the non-cached variable and does not create the cache-variable
* this is not described in the docs
* the docs should also describe when and how the cached-variable and the non-cached variable is read and written
* same goes for all `find_*`-commands
`MARK_AS_ADVANCED()` for an undefined cache-variable creates the cache-var with and empty value and type 'UNDEFINED'
* Is this a bug(?)
* It could use the value of the non-cached variable (if there is one)
* or it should not set the VALUE-property of the cached variable
* or set the type to 'STRING'
The 2nd `FIND_PATH()` does not use the non-cached variable as in the first call, but clears the variable without search for the path
* For me this looks like a bug!
3.17.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/16509FindCuda: unknown CMake command "find_host_program"2017-07-11T05:35:18-04:00Francesco RomanoFindCuda: unknown CMake command "find_host_program"I have a library which searches for Cuda (and if it finds it it enables some options, otherwise not).
When trying to cross compiling for iOS I have the following error:
```
CMake Error at /usr/local/Cellar/cmake/3.7.1/share/cmake/Module...I have a library which searches for Cuda (and if it finds it it enables some options, otherwise not).
When trying to cross compiling for iOS I have the following error:
```
CMake Error at /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FindCUDA.cmake:675 (find_host_program):
Unknown CMake command "find_host_program".
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FindCUDA.cmake:687 (cuda_find_host_program)
cmake/YarpFindDependencies.cmake:387 (find_package)
CMakeLists.txt:62 (include)
```
Any clue on this error?https://gitlab.kitware.com/cmake/cmake/-/issues/16469Problem using NASM on Visual Studio target (CMake v3.7)2019-03-05T06:32:31-05:00Robert BielikProblem using NASM on Visual Studio target (CMake v3.7)I'm adding NASM assembly files with:
```
enable_language(ASM_NASM)
...
add_library(test STATIC rdrand-x86_64.asm)
```
The NASM assembler is found, but the target generates the following vcxproj entries:
```
<ItemGroup>
<None Incl...I'm adding NASM assembly files with:
```
enable_language(ASM_NASM)
...
add_library(test STATIC rdrand-x86_64.asm)
```
The NASM assembler is found, but the target generates the following vcxproj entries:
```
<ItemGroup>
<None Include="....\test\rdrand-x86_64.asm" />
</ItemGroup>
```
Note the **None** element, which just includes the asm file into the test target, but nothing is compiled.https://gitlab.kitware.com/cmake/cmake/-/issues/25265CLANG_TIDY property unexpected behavior with Generator Expression revaluating...2023-09-26T11:22:38-04:00Nick SchultzCLANG_TIDY property unexpected behavior with Generator Expression revaluating to empty stringI'm trying to use generator expressions in the `CXX_CLANG_TIDY` target property:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:TRUE>,${CLANG_TIDY_CMD},>")
```
behaves appropriately, I see clang-tidy getting...I'm trying to use generator expressions in the `CXX_CLANG_TIDY` target property:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:TRUE>,${CLANG_TIDY_CMD},>")
```
behaves appropriately, I see clang-tidy getting invoked with the contents of `${CLANG_TIDY_CMD}`
However, if the genex evaluates to an empty string:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "<IF:$<BOOL:FALSE>,${CLANG_TIDY_CMD},>")
```
I see an unexpected result (notice the genex is present in the `--tidy` command):
```plaintext
[build] FAILED: foo.cpp.o [build] cmake -E __run_co_compile --tidy="$<IF:$<BOOL:FALSE>,clang-tidy;--config-file=clang_tidy.current;-header-filter=foo/*,>;--extra-arg-before=--driver-mode=g++" --source=foo.cpp ...
```
I would expect the previous genex statement to behave similar to:
```cmake
set_property(TARGET ${TARGET} PROPERTY CXX_CLANG_TIDY "")
```
Which does not invoke clang-tidy.
Looking in the code, I am able to see that if the general expression evaluates to an empty string, the lambda `evaluateProp` returns the original string ( `value` ) here:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.27.6/Source/cmCommonTargetGenerator.cxx#L330-342
```cpp
auto evaluateProp = [&](std::string const& prop) -> std::string {
auto const value = this->GeneratorTarget->GetProperty(prop);
if (!value) {
return std::string{};
}
auto evaluatedProp = cmGeneratorExpression::Evaluate(
*value, this->GeneratorTarget->GetLocalGenerator(), config,
this->GeneratorTarget, nullptr, this->GeneratorTarget, lang);
if (!evaluatedProp.empty()) {
return evaluatedProp;
}
return *value;
};
std::string const tidy_prop = cmStrCat(lang, "_CLANG_TIDY");
tidy = evaluateProp(tidy_prop);
```3.27.7Orkun TokdemirOrkun Tokdemirhttps://gitlab.kitware.com/cmake/cmake/-/issues/23733Using ninja multi-config and exporting compile commands produces duplicates i...2022-07-18T10:19:48-04:00Daniel HannonUsing ninja multi-config and exporting compile commands produces duplicates in compile_commands.jsonHi. Running this:
```bash
export CMAKE_BIN=path/to/cmake
${CMAKE_BIN} \
-G "Ninja Multi-Config" \
-DCMAKE_CROSS_CONFIGS=all \
...Hi. Running this:
```bash
export CMAKE_BIN=path/to/cmake
${CMAKE_BIN} \
-G "Ninja Multi-Config" \
-DCMAKE_CROSS_CONFIGS=all \
-DCMAKE_DEFAULT_CONFIGS="Release" \
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" \
-DCMAKE_VERIFY_INTERFACE_HEADER_SETS=TRUE \
-DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE \
.
cat compile_commands.json
```
Produced this output
```json
[
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DFOO_BAR -DCMAKE_INTDIR=\\\"Release\\\" -I/root/minimal/minimal/. -O3 -DNDEBUG -o CMakeFiles/blah.dir/Release/blah.cpp.o -c /root/minimal/minimal/blah.cpp",
"file": "/root/minimal/minimal/blah.cpp"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DFOO_BAR -DCMAKE_INTDIR=\\\"Release\\\" -I/root/minimal/minimal/. -O3 -DNDEBUG -o CMakeFiles/blah.dir/Release/blah.cpp.o -c /root/minimal/minimal/blah.cpp",
"file": "/root/minimal/minimal/blah.cpp"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DFOO_BAR -DCMAKE_INTDIR=\\\"Debug\\\" -I/root/minimal/minimal/. -g -o CMakeFiles/blah.dir/Debug/blah.cpp.o -c /root/minimal/minimal/blah.cpp",
"file": "/root/minimal/minimal/blah.cpp"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DFOO_BAR -DCMAKE_INTDIR=\\\"Debug\\\" -I/root/minimal/minimal/. -g -o CMakeFiles/blah.dir/Debug/blah.cpp.o -c /root/minimal/minimal/blah.cpp",
"file": "/root/minimal/minimal/blah.cpp"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DCMAKE_INTDIR=\\\"Release\\\" -I/root/minimal/minimal/. -x c++ -O3 -DNDEBUG -o CMakeFiles/blah_verify_interface_header_sets.dir/Release/blah_verify_interface_header_sets/blah.h.cxx.o -c /root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx",
"file": "/root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DCMAKE_INTDIR=\\\"Release\\\" -I/root/minimal/minimal/. -x c++ -O3 -DNDEBUG -o CMakeFiles/blah_verify_interface_header_sets.dir/Release/blah_verify_interface_header_sets/blah.h.cxx.o -c /root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx",
"file": "/root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DCMAKE_INTDIR=\\\"Debug\\\" -I/root/minimal/minimal/. -x c++ -g -o CMakeFiles/blah_verify_interface_header_sets.dir/Debug/blah_verify_interface_header_sets/blah.h.cxx.o -c /root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx",
"file": "/root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx"
},
{
"directory": "/root/minimal/minimal",
"command": "/usr/local/bin/clang++ -DCMAKE_INTDIR=\\\"Debug\\\" -I/root/minimal/minimal/. -x c++ -g -o CMakeFiles/blah_verify_interface_header_sets.dir/Debug/blah_verify_interface_header_sets/blah.h.cxx.o -c /root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx",
"file": "/root/minimal/minimal/blah_verify_interface_header_sets/blah.h.cxx"
}
]
```
on this codebase
blah.h
```cpp
int ab(int a, int b);
```
blah.cpp
```cpp
#include <blah.h>
#include <iostream>
int ab(int a, int b)
{
return a + b;
}
```
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.24.0)
project(MINIMAL)
add_library(blah blah.cpp)
add_compile_definitions(FOO_BAR)
target_include_directories(blah PUBLIC .)
target_sources(blah PUBLIC
FILE_SET internal_h_files
TYPE HEADERS
BASE_DIRS .
FILES blah.h)
#set_property(TARGET blah PROPERTY EXPORT_COMPILE_COMMANDS FALSE)
```
I am using the latest cmake release candidate for what it's worthhttps://gitlab.kitware.com/cmake/cmake/-/issues/23595ExternalProject: Unable to use cross-config BUILD_BYPRODUCTS with Ninja Multi...2022-06-10T12:46:12-04:00Jørgen LindExternalProject: Unable to use cross-config BUILD_BYPRODUCTS with Ninja Multi-ConfigAttached project shows an issue when specifying BUILD_BYPRODUCTS to ExternalProject_Add fails when the BYPRODUCTS are using generator expressions under a Ninja Multi-Config setup.
[multi-config-external-project.tar.gz](/uploads/81e0de31...Attached project shows an issue when specifying BUILD_BYPRODUCTS to ExternalProject_Add fails when the BYPRODUCTS are using generator expressions under a Ninja Multi-Config setup.
[multi-config-external-project.tar.gz](/uploads/81e0de31e78e717f37630f98f8af4bc4/multi-config-external-project.tar.gz)3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23348ExternalProject_Add USES_TERMINAL_* flags should make SVN interactive2022-05-13T08:51:12-04:00rbprogrammerExternalProject_Add USES_TERMINAL_* flags should make SVN interactiveThe latest CMake docs for [ExternalProject_Add()](https://cmake.org/cmake/help/latest/module/ExternalProject.html) describe how to use the directive to download external dependencies through version control systems like Git, Subversion, ...The latest CMake docs for [ExternalProject_Add()](https://cmake.org/cmake/help/latest/module/ExternalProject.html) describe how to use the directive to download external dependencies through version control systems like Git, Subversion, and others.
The docs also mention a section called "Terminal Access Options" (since 3.4) that grant various steps access to the terminal. However, for at least Subversion in the download step, CMake hard codes "--non-interactive" to the Subversion checkout command
* https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.0/Modules/ExternalProject.cmake#L2530-2531
* `set(cmd ${Subversion_SVN_EXECUTABLE} co ${svn_repository} ${svn_revision} --non-interactive ${svn_trust_cert_args} ${svn_user_pw_args} ${src_name})`
The easiest way to test this is to:
```
ExternalProject_Add(
myextdep
USES_TERMINAL_DOWNLOAD true
SVN_REPOSITORY https://example.com/path/to/username-password/protected/repo
)
```
One workaround would have been to use the `SVN_USERNAME` and `SVN_PASSWORD` options to `ExternalProject_Add()`. However that does not work when the username/password is not predictable, nor in situations where we cannot put username/passwords into CMake scripts, or piped in with environment variables, etc. The desired behaviour I would have expected would pause the Subversion checkout process with a prompt asking for the Subversion username/password as if the user ran the "svn co ..." command directly. This is why the `USES_TERMINAL_*` options exist, right?
I considered adding submitting a patch rather than raise a discussion here, but I do not believe fixing Subversion in the Download step is the complete solution. I am not sure how wide this bug effects. Is it all VCS types? Is it all `USES_TERMINAL_*` flags?
I'm hoping someone with more historical knowledge of the ExternalProject_Add functionality can chime in. Is this a bug? Or am I using `ExternalProject_Add()` + `USES_TERMINAL_*` incorrectly?
Thanks in advanced!
PS. Discussion started on Discourse: https://discourse.cmake.org/t/externalproject-add-does-not-respect-uses-terminal-flags/52543.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/22956FindPython: Python_USE_STATIC_LIBS swallowed without warning on Windows2021-12-02T11:48:43-05:00Oliver SmithFindPython: Python_USE_STATIC_LIBS swallowed without warning on WindowsWhen using the Find_Python modules on Windows, the Python_USE_STATIC_LIBS is actively swallowed. This appears to be based on magic knowledge that the python project is currently unable to produce static libraries on Windows. (If only the...When using the Find_Python modules on Windows, the Python_USE_STATIC_LIBS is actively swallowed. This appears to be based on magic knowledge that the python project is currently unable to produce static libraries on Windows. (If only they used CMake :(
While this _is_ actually a hint flag, quietly encoding magic knowledge can be surprising to end-users who, elsewhere, who may not have fully cognized that it is _actively_ supressed by CMake on Windows:
Find_Python/Support.cmake:
```
unset (_${_PYTHON_PREFIX}_CMAKE_FIND_LIBRARY_SUFFIXES)
if (DEFINED ${_PYTHON_PREFIX}_USE_STATIC_LIBS AND NOT WIN32)
set(_${_PYTHON_PREFIX}_CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
if(${_PYTHON_PREFIX}_USE_STATIC_LIBS)
set (CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_STATIC_LIBRARY_SUFFIX})
else()
list (REMOVE_ITEM CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_STATIC_LIBRARY_SUFFIX})
endif()
endif()
```
Sample CMake:
```
CMAKE_MINIMUM_REQUIRED(VERSION 3.18)
PROJECT(Test)
SET(Python_USE_STATIC_LIBS ON)
FIND_PACKAGE(Python REQUIRED COMPONENTS Development.embed)
IF (_Python_LIBRARY_TYPE STREQUAL "SHARED")
MESSAGE(FATAL_ERROR "shared python selected.") # Fails on windows
ENDIF()
```
Discussion thread: https://discourse.cmake.org/t/static-python-on-windows-find-python/4427/2https://gitlab.kitware.com/cmake/cmake/-/issues/16499strip requires -ru on Darwin to actually strip dylibs2019-02-06T10:12:37-05:00Jim Radfordstrip requires -ru on Darwin to actually strip dylibsWhile plain `strip` on OS X actually strips the symbols of executables, for shared libraries it just prints the symbol table. In order to actually strip the symbols you must pass `-r -u`, but `cmake` currently does not support passing op...While plain `strip` on OS X actually strips the symbols of executables, for shared libraries it just prints the symbol table. In order to actually strip the symbols you must pass `-r -u`, but `cmake` currently does not support passing options to `strip`.https://gitlab.kitware.com/cmake/cmake/-/issues/16460AUTOMOC shares .moc files between different configurations2018-02-20T16:28:55-05:00Susumu AraiAUTOMOC shares .moc files between different configurationsAUTOMOC runs moc with different options for different configurations (e.g. AM_MOC_COMPILE_DEFINITIONS vs AM_MOC_COMPILE_DEFINITIONS_Debug in AutogenInfo.cmake) and the auto-generated MOC files can be different from configuration to confi...AUTOMOC runs moc with different options for different configurations (e.g. AM_MOC_COMPILE_DEFINITIONS vs AM_MOC_COMPILE_DEFINITIONS_Debug in AutogenInfo.cmake) and the auto-generated MOC files can be different from configuration to configuration. But, CMake shares exact same directory / file name for the MOC file between different configurations.
This works ok as long as the build is done from scratch (with no auto-generated MOC file before the build). But, if a project is built for one configuration and re-built for another configuration, MOC files are not re-generated for the second build. As a result, it can cause compile error, or even worse, build succeeds with unintended MOC file.https://gitlab.kitware.com/cmake/cmake/-/issues/16444compile_commands.json should be included in Ninja list of files generated by ...2017-07-11T05:35:18-04:00Kevin Puetzcompile_commands.json should be included in Ninja list of files generated by configurationI'm trying to write a rule that runs clang-tooling based commands whenever the source files or options change.
Completion is tracked by a witness file that gets touched when the tooling runs, but to rerun if the options change this comm...I'm trying to write a rule that runs clang-tooling based commands whenever the source files or options change.
Completion is tracked by a witness file that gets touched when the tooling runs, but to rerun if the options change this command should depend on the compile_commands.json. However, CMake rejects this with
> CMake Warning (dev):
> Policy CMP0058 is not set: Ninja requires custom command byproducts to be
> explicit. Run "cmake --help-policy CMP0058" for policy details. Use the
> cmake_policy command to set the policy and suppress this warning.
>
> This project specifies custom command DEPENDS on files in the build tree
> that are not specified as the OUTPUT or BYPRODUCTS of any
> add_custom_command or add_custom_target:
I think the needed fix would be to have cmGlobalNinjaGenerator::WriteUnknownExplicitDependencies include compile_commands.json in knownDependencies when CMAKE_EXPORT_COMPILE_COMMANDS is true. This seems like it would fit here, as the comment describing this section is
```
// get the list of files that cmake itself has generated as a
// product of configuration.
```https://gitlab.kitware.com/cmake/cmake/-/issues/16389Ninja build fails when adding files that depend on AUTOMOC2017-05-04T16:23:55-04:00Vidar Meland ØdegårdNinja build fails when adding files that depend on AUTOMOCSteps to repdroduce (tested on CMake 3.6.2)
* configure
* build
* uncomment line in CMakeLists.txt
* build
[testproject.tar.gz](/uploads/6051bb1605fbf12d7c112c8ee2318e5a/testproject.tar.gz)Steps to repdroduce (tested on CMake 3.6.2)
* configure
* build
* uncomment line in CMakeLists.txt
* build
[testproject.tar.gz](/uploads/6051bb1605fbf12d7c112c8ee2318e5a/testproject.tar.gz)