CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-06-22T11:59:34-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25015Setting CMAKE_OBJECT_PATH_MAX does not solve path length issue2023-06-22T11:59:34-04:00Rene BartoSetting CMAKE_OBJECT_PATH_MAX does not solve path length issueOn Windows, we get the issue that paths are too long. We have long paths enabled (Windows 10) but CMake does not recognize this.
As a fallback we set the `CMAKE_OBJECT_PATH_MAX` variable to `512` to get some air. This seems to work well...On Windows, we get the issue that paths are too long. We have long paths enabled (Windows 10) but CMake does not recognize this.
As a fallback we set the `CMAKE_OBJECT_PATH_MAX` variable to `512` to get some air. This seems to work well, however, in a specific case it still fails:
```
<built-in>:0:0: fatal error: opening dependency file CMakeFiles/generic-fxddpxdefectmapconverter-test.dir/__/__/__/__/libraries/generic/src/ImageFormat/FXDDPXDefectMapConverter.cpp.o.d: No such file or directory
compilation terminated.
```
So apparently, the lookup of `.d` files does not use this path length, and so cannot find the file.
The full path in our case is `D:\SandboxGIT\IC-ImageDetection-SW\root\DTC_SW\cmake-WRLinux-Release-Cov\code\tests\generic\ImageFormat\FXDDPXDefectMapConverter\CMakeFiles\generic-fxddpxdefectmapconverter-test.dir\__\__\__\__\libraries\generic\src\ImageFormat`, which is 225 characters.
So two questions:
- When will CMake start supporting long paths on Windows?
- Is there a bug somewhere inside CMake, that makes it not use the max path length?
For your information, we are using CMake 3.20.3.https://gitlab.kitware.com/cmake/cmake/-/issues/25013VS: Relative Paths in Generated Visual Studio Files, Again2023-07-05T08:05:39-04:00geometrianVS: Relative Paths in Generated Visual Studio Files, AgainThe generated "*.vcxproj.filters" files have absolute paths in them for the "`Include`" attribute of "`ClInclude`" (the tag for each referenced file). This fact has been raised in various places a few times as an issue (e.g. ([1](https:...The generated "*.vcxproj.filters" files have absolute paths in them for the "`Include`" attribute of "`ClInclude`" (the tag for each referenced file). This fact has been raised in various places a few times as an issue (e.g. ([1](https://discourse.cmake.org/t/generating-vcxproj-that-uses-relative-paths/1522/2)), ([2](
https://cmake.cmake.narkive.com/qLfS2PnQ/how-to-make-visual-studio-vcproj-with-relative-paths)), ([3](https://github.com/unittest-cpp/unittest-cpp/issues/47))). Each time, the motivation has been because the user wanted to redistribute project files. The concern has therefore been dismissed because CMake's model is for project files to be regenerated instead of redistributed.
What seems to have escaped notice, however, is that there are better reasons to use relative paths.
---
As it happens, I have a motivating example I'd like to raise. In the large projects CMake is good at managing, it happens that there are files with the same filename in different directories. In projects with thousands of source files, it is not reasonable to ensure all names are distinct, even if you *wanted* to do that. Moreover, note that there are *good reasons to do this*—for example, separate but analogous implementations for different platforms.
Nevertheless, Visual Studio, in its infinite wisdom, dumps all built objects into the same directory by default, leading to (silent!) breakage. The only way to solve this (e.g. ([4](https://stackoverflow.com/questions/14364362/visualstudio-project-with-multiple-sourcefiles-of-the-same-name)) ([5](https://stackoverflow.com/questions/76055294/relative-output-directory-for-object-file-name))) is to set "Configuration Properties -> C/C++ -> Output Files -> Output File Name" to something like "`$(IntDir)\%(RelativeDir)\%(Filename).obj`".
The problem is that the file-varying macro "`%(RelativeDir)`" is essentially a synonym for the directory of the "`Include`" attribute of each file referenced in the "*.vcxproj.filters" file. If you use the Visual Studio GUI to add files instead of CMake, the paths will indeed be written into that file as relative paths. However, CMake writes an absolute path, breaking everything. From this behavior, we can see that Microsoft's definition of that field is that it is relative. This can be proved by looking at Microsoft's specification ([6](https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/msbuild/msbuild-well-known-item-metadata?view=vs-2015&viewFallbackFrom=vs-2017)):
> %(RelativeDir) Contains the path specified in the `Include` attribute, up to the final backslash (\\).
However, CMake is *violating* that assumption, and it is only an *accident* that absolute paths, shoved into the location meant for relative paths, happen to work *most* of the time. As we see, it *doesn't* work in this use-case.
---
While I appreciate the bravery of using absolute paths everywhere, in this case it goes against the literal definition of the file CMake is trying to generate, and it causes real-world problems that are impossible to work around in any reasonable way. Please fix this. Thank you.https://gitlab.kitware.com/cmake/cmake/-/issues/25012RC: rc flags get passed to compiler2023-06-22T12:04:49-04:00saunter_pearled0hRC: rc flags get passed to compilerCMake seems to pass RC flags to compiler.
```cmake
set(CMAKE_RC_FLAGS "/C 65001")
```
this will result in
```
cmcldeps.exe RC C:\project\project\version.rc project\CMakeFiles\project.dir\version.rc.res.d project\CMakeFiles\project.dir...CMake seems to pass RC flags to compiler.
```cmake
set(CMAKE_RC_FLAGS "/C 65001")
```
this will result in
```
cmcldeps.exe RC C:\project\project\version.rc project\CMakeFiles\project.dir\version.rc.res.d project\CMakeFiles\project.dir\version.rc.res "Note: including file: " "C:/Program Files/LLVM/bin/clang-cl.exe" C:\PROGRA~1\LLVM\bin\llvm-rc.exe -Dproject_EXPORTS /C 65001 /fo project\CMakeFiles\project.dir\version.rc.res C:\project\project\version.rc
clang-cl: error: no such file or directory: '65001'
```
Generator used: Ninjahttps://gitlab.kitware.com/cmake/cmake/-/issues/25011FindProtobuf: `PROTOBUF_USE_DLLS` should be defined when protobuf libraries a...2023-07-07T10:29:35-04:00مهدي شينون (Mehdi Chinoune)FindProtobuf: `PROTOBUF_USE_DLLS` should be defined when protobuf libraries are dynamic/sharedProtobuf>=22.0 requires projects to define `PROTOBUF_USE_DLLS` to build against its shared/dynamic libraries.
see: https://github.com/protocolbuffers/protobuf/blob/v22.0/cmake/README.md?plain=1#L298Protobuf>=22.0 requires projects to define `PROTOBUF_USE_DLLS` to build against its shared/dynamic libraries.
see: https://github.com/protocolbuffers/protobuf/blob/v22.0/cmake/README.md?plain=1#L298https://gitlab.kitware.com/cmake/cmake/-/issues/25009CMake can't find Python 3.10 installed via conda2023-06-20T09:44:08-04:00OrispheraCMake can't find Python 3.10 installed via conda<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
I want to make a Blender fork. I've already created a GitHub repository and cloned it, but can't build it: `make` and `make project_eclipse` output the following error:
```
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
'PYTHON_VERSION=3.10' not found! This is the only officially supported
version. If you wish to use a newer Python version you may set
'PYTHON_VERSION' however we do not guarantee full compatibility in this
case. (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR
PYTHON_INCLUDE_CONFIG_DIR)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
build_files/cmake/Modules/FindPythonLibsUnix.cmake:183 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
build_files/cmake/platform/platform_unix.cmake:159 (find_package)
CMakeLists.txt:1100 (include)
```
I run it in a conda environment with Python 3.10.11 on Fedora.https://gitlab.kitware.com/cmake/cmake/-/issues/25008Support for ASM for GHS.2023-06-20T08:23:59-04:00Kaushal JangidSupport for ASM for GHS.<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->https://gitlab.kitware.com/cmake/cmake/-/issues/25006Feature Request: fortran language standard support2024-02-03T09:35:54-05:00wolfman21Feature Request: fortran language standard supportHello,
GFortran supports passing the Fortran standard via `-std=[f95|f2003|f2008|...]`
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#index-std_003dstd-option
It appears that Fortran isn't supported as a language ...Hello,
GFortran supports passing the Fortran standard via `-std=[f95|f2003|f2008|...]`
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#index-std_003dstd-option
It appears that Fortran isn't supported as a language in CMAKE_<LANG>_STANDARD:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_STANDARD.html#variable:CMAKE_%3CLANG%3E_STANDARD
Could this be added?
Thank you.
----
For reference, a cmake discourse issue on this is here: https://discourse.cmake.org/t/setting-fortran-language-standard/8351https://gitlab.kitware.com/cmake/cmake/-/issues/25005FindOpenMP: Component for OpenMP tools interface (OMPT)2023-06-19T06:49:16-04:00Peter ArztFindOpenMP: Component for OpenMP tools interface (OMPT)Compilers that support the [OpenMP tools interface](https://www.openmp.org/spec-html/5.0/openmpsu15.html#x25-240001.5.1) define a header called `omp-tools.h` that declares functions which can be used to trace or sample information about ...Compilers that support the [OpenMP tools interface](https://www.openmp.org/spec-html/5.0/openmpsu15.html#x25-240001.5.1) define a header called `omp-tools.h` that declares functions which can be used to trace or sample information about the OpenMP execution at runtime.
Clang/LLVM supports this, but for example GOMP (GCC) currently doesn't.
In a short exchange I had with @ben.boeckel [on Discourse](https://discourse.cmake.org/t/find-omp-tools-h-with-findopenmp/8275), we agreed it would be useful to express this as a component so that developers of tools that use OMPT can make sure it is compiled using a suitable compiler.
The goal would be to support something like this: `find_package(OpenMP 5.0 REQUIRED COMPONENTS ompt)`.
I am currently unsure how to approach this and won't work on it for now, but will try to get back to it at a later date.https://gitlab.kitware.com/cmake/cmake/-/issues/25003VS: VS_USER_PROPS should allow multiple property sheets2023-06-20T10:47:49-04:00David HunterVS: VS_USER_PROPS should allow multiple property sheetsCurrently you can add the following to your `CMakeLists.txt`
```
set_target_properties(target_name PROPERTIES VS_USER_PROPS "A.props")
```
which results in the following in the generated `vcxproj` file
```
<ImportGroup Label="PropertyS...Currently you can add the following to your `CMakeLists.txt`
```
set_target_properties(target_name PROPERTIES VS_USER_PROPS "A.props")
```
which results in the following in the generated `vcxproj` file
```
<ImportGroup Label="PropertySheets">
<Import Project="...\A.props" Condition="exists('...\A.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
```
which is great. However if you try to add two
```
set_target_properties(target_name PROPERTIES VS_USER_PROPS "A.props")
set_target_properties(target_name PROPERTIES VS_USER_PROPS "B.props")
```
you see
```
<ImportGroup Label="PropertySheets">
<Import Project="...\B.props" Condition="exists('...\B.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
```
so only the last one gets added.
This issue is to request that you can add multiple property sheets so you would see
```
<ImportGroup Label="PropertySheets">
<Import Project="...\A.props" Condition="exists('...\A.props')" Label="LocalAppDataPlatform" />
<Import Project="...\B.props" Condition="exists('...\B.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
```
Note they appear in the `vcxproj` file in the in the order in which they appear in the `CMakelists.txt`https://gitlab.kitware.com/cmake/cmake/-/issues/25001FindPython: Specify the SOABI when cross compiling2023-06-22T10:46:30-04:00Henry SchreinerFindPython: Specify the SOABI when cross compilingWhen cross-compiling (currently I'm trying to support Windows ARM), FindPython doesn't support setting the SOABI as an input value. The other aspects of cross compiling work normally, but the SOABI comes out wrong, and it's a pain to do ...When cross-compiling (currently I'm trying to support Windows ARM), FindPython doesn't support setting the SOABI as an input value. The other aspects of cross compiling work normally, but the SOABI comes out wrong, and it's a pain to do this by hacking sysconfig so Python lies about the value when asked (which is what I'm working on now). It would be really nice to have some way to specify this as an input value for FindPython.
Setuptools supports the environment variable `SETUPTOOLS_EXT_SUFFIX` for cross-compiling, some environments, like cibuildwheel, set this when cross-compiling. Not a great name for the variable, setting this via CMake variable is probably better.
Passing in something like `-DPython_SOABI=...` would be ideal, since it doesn't require learning/documenting another variable, but I think it might not be supported in the current design, so some custom variable (like `-DPython_TARGET_SOABI` or something) would be fine too. It would also be useful when not cross-compiling to avoid an extra Python process launch if the value is known ahead of time (like in scikit-build-core).
(Whatever is selected should support SOSABI, obviously, which is another count against the existing setuptools environment variable)
Thoughts?https://gitlab.kitware.com/cmake/cmake/-/issues/25000Cray Fortran OpenMP support and deduplication issue2023-06-15T09:11:07-04:00etiennemlbCray Fortran OpenMP support and deduplication issueHi, using:
```
target_link_libraries(mylib PRIVATE OpenMP::OpenMP_Fortran)
```
in CMake version 3.25.2 (and earlier) with the Cray Fortran compiler, CMake produces the compiler option:
```
-h omp
```
If the user wishes to add other `-h ...Hi, using:
```
target_link_libraries(mylib PRIVATE OpenMP::OpenMP_Fortran)
```
in CMake version 3.25.2 (and earlier) with the Cray Fortran compiler, CMake produces the compiler option:
```
-h omp
```
If the user wishes to add other `-h <options>` such as `-h ipa3,mpi0,pattern,modinline`, the `-h` specified in `-h omp` will (or may?) disappear, effectively disabling OpenMP.
This looks like an unfortunate, common deduplication issue which should be fixed via:
`SHELL:-h omp`https://gitlab.kitware.com/cmake/cmake/-/issues/24999CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS exports the symbole "==" on debug. This resu...2023-06-14T07:31:33-04:00Ludwig FüchslCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS exports the symbole "==" on debug. This results in LNK2001 causing LNK1120Hello,
I recently encountered an issue with the `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` variable on Debugging builds. As it appears, CMake tries to export the symbol `==`. This leads to linker issues because the symbol is undefined. In norma...Hello,
I recently encountered an issue with the `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS` variable on Debugging builds. As it appears, CMake tries to export the symbol `==`. This leads to linker issues because the symbol is undefined. In normal release configuration, everything works fine.
I have attached a "minimal" reproduction example. This example requires python to be installed, since the source of the lib causing the issue is compiled using Conan.
**This is the CMake output**:
```
...
pool.cpp
Auto build dll exports
exports.def : error LNK2001: Nicht aufgelöstes externes Symbol "=". [C:\Users\<USERNAME>\.conan2\p\b\nanaeca088313ac73\b\build\nana.vcxproj]
C:/Users/<USERNAME>/.conan2/p/b/nanaeca088313ac73/b/build/Debug/nana.lib : fatal error LNK1120: 1 nicht aufgelöste Externe [C:\Users\<USERNAME>\.conan2\p\b\nanaeca088313ac73\b\build\nana.vcxproj]
```
**Section of `exports.def`**:
```
EXPORTS
...
?use_throw@utf8_Error@nana@@2_NA DATA
==
??$?0$$BY0BAE@_W$0A@@path@filesystem@std@@QEAA@AEAY0BAE@$$CB_WW4format@012@@Z
...
```
**Steps to reproduce**:
- Open PowerShell in the directory where the unzipped content is located.
- Run `./venv.ps1`. This will set up a virtual python environment and installs Conan into it.
- Run `./build.ps1`. This will set up Conan and compile the lib in the correct configuration (MSVC VS2022 Debug).
- Error reproduced as shown in the output.
- The source will be located under a Conan folder. The path is shown in the output right before the CMake build `Building your package in ...`. (For me: `C:\Users\<USERNAME>\.conan2\p\b\nanaeca088313ac73\b`)
Thank you for your Help!
[cmake_exportall.zip](/uploads/cbd98a524ff827bfd028be55675ffd13/cmake_exportall.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/24998Ninja: add_dependencies wrong build order with `-j2`2023-06-14T21:51:32-04:00huangqinjinNinja: add_dependencies wrong build order with `-j2`## Environment
- CMake: 3.26.4
- Ninja: 1.11.1
- GCC: 13.1.1
- OS: Linux
## Steps to reproduce
main.cpp
```c++
import hello;
int main() { hello(); }
```
hello.cpp
```c++
export module hello;
export void hello() {}
```
CMakeLists.txt
`...## Environment
- CMake: 3.26.4
- Ninja: 1.11.1
- GCC: 13.1.1
- OS: Linux
## Steps to reproduce
main.cpp
```c++
import hello;
int main() { hello(); }
```
hello.cpp
```c++
export module hello;
export void hello() {}
```
CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.26)
project(hello)
set(CMAKE_CXX_STANDARD 20)
add_compile_options(-fmodules-ts -Mno-modules)
add_library(hello STATIC hello.cpp)
add_executable(prog main.cpp)
target_link_libraries(prog hello)
add_dependencies(prog hello)
```
Build with `ninja -v -j2`:
```
[1/4] /usr/bin/c++ -std=gnu++20 -fmodules-ts -Mno-modules -MD -MT CMakeFiles/prog.dir/main.cpp.o -MF CMakeFiles/prog.dir/main.cpp.o.d -o CMakeFiles/prog.dir/main.cpp.o -c /home/huangqinjin/tmp/main.cpp
FAILED: CMakeFiles/prog.dir/main.cpp.o
/usr/bin/c++ -std=gnu++20 -fmodules-ts -Mno-modules -MD -MT CMakeFiles/prog.dir/main.cpp.o -MF CMakeFiles/prog.dir/main.cpp.o.d -o CMakeFiles/prog.dir/main.cpp.o -c /home/huangqinjin/tmp/main.cpp
In module imported at /home/huangqinjin/tmp/main.cpp:1:1:
hello: error: failed to read compiled module: No such file or directory
hello: note: compiled module file is ‘gcm.cache/hello.gcm’
hello: note: imports must be built before being imported
hello: fatal error: returning to the gate for a mechanical issue
compilation terminated.
[2/4] /usr/bin/c++ -std=gnu++20 -fmodules-ts -Mno-modules -MD -MT CMakeFiles/hello.dir/hello.cpp.o -MF CMakeFiles/hello.dir/hello.cpp.o.d -o CMakeFiles/hello.dir/hello.cpp.o -c /home/huangqinjin/tmp/hello.cpp
ninja: build stopped: subcommand failed.
```
Ninja built `main.cpp` first instead of `hello.cpp`. Using Makefile does not have this issue.https://gitlab.kitware.com/cmake/cmake/-/issues/24997fileapi: Generate reply if special environment variable (`CMAKE_FILE_API`) is...2023-11-10T14:53:43-05:00Semyon Koltonfileapi: Generate reply if special environment variable (`CMAKE_FILE_API`) is setWith CMake 3.27 there are only 2 ways to force the generation of file API reply:
- put special `query` files into the project build directory
- add `cmake_file_api()` command into CMakeLists.txt - #24951
For an IDE, it would be much e...With CMake 3.27 there are only 2 ways to force the generation of file API reply:
- put special `query` files into the project build directory
- add `cmake_file_api()` command into CMakeLists.txt - #24951
For an IDE, it would be much easier and less invasive to simply specify some environment variable - e.g. `CMAKE_FILE_API`. If CMake sees such a variable, it can generate a corresponding file API reply.
Additionally, CMake can generate file API response in some external location, instead of the project build directory.
This feature would be useful for CLion to implement this feature: https://youtrack.jetbrains.com/issue/CPP-8414
Also, it can be useful for #22826https://gitlab.kitware.com/cmake/cmake/-/issues/24996CheckCXXSourceCompiles function does not respect CMAKE_CXX_STANDARD_INCLUDE_D...2023-06-13T12:08:32-04:00Solganik AlexanderCheckCXXSourceCompiles function does not respect CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES or CMAKE_CXX_STANDARD_LIBRARIESI`m using cmake cmake version 3.26.4.
Having this simple cmakefile
```cmake
project(test_proj)
set(CMAKE_CXX_STANDARD 17)
set(DEFAULT_LIBS "-nodefaultlibs /usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.builtins-x86_64.a -lc...I`m using cmake cmake version 3.26.4.
Having this simple cmakefile
```cmake
project(test_proj)
set(CMAKE_CXX_STANDARD 17)
set(DEFAULT_LIBS "-nodefaultlibs /usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.builtins-x86_64.a -lc -lm -lrt -lpthread -ldl")
set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES "path here")
set(CMAKE_CXX_STANDARD_LIBRARIES ${DEFAULT_LIBS})
include(CheckCXXSourceCompiles)
check_cxx_source_compiles(
"#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
int main()
{
struct statx st;
int res = statx(AT_FDCWD, \".\", AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT, STATX_BTIME, &st);
st.stx_btime.tv_sec = 1;
st.stx_btime.tv_nsec = 10;
}" DO_I_HAVE_STATX)
if (NOT DO_I_HAVE_STATX)
message(FATAL_ERROR "DONT HAVE STATX")
else()
message(WARNING "HAVE STATX")
endif()
```
Now by running:
```
cmake -G Ninja -DCMAKE_C_COMPILER=/usr/bin/clang-14 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-14 ../ --debug-trycompile --trace --debug-output
```
and looking at the cmake file that it generates i get:
```cmake
cmake_minimum_required(VERSION 3.26.4.0)
project(CMAKE_TRY_COMPILE CXX)
set(CMAKE_VERBOSE_MAKEFILE 1)
set(CMAKE_CXX_FLAGS "")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_DEFINITIONS}")
set(CMAKE_CXX_FLAGS_DEBUG "-g")
set(CMAKE_EXE_LINKER_FLAGS "")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${EXE_LINKER_FLAGS}")
include_directories(${INCLUDE_DIRECTORIES})
set(CMAKE_SUPPRESS_REGENERATION 1)
link_directories(${LINK_DIRECTORIES})
add_definitions([==[-DHAVE_ERROR_STOP]==])
cmake_policy(SET CMP0065 NEW)
cmake_policy(SET CMP0083 NEW)
include("${CMAKE_ROOT}/Modules/Internal/HeaderpadWorkaround.cmake")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "/home/sashas/workspace/test_proj/cmake-build-debug/CMakeFiles/CMakeScratch/TryCompile-JiULQF")
add_executable(cmTC_f4d2a "/home/sashas/workspace/test_proj/cmake-build-debug/CMakeFiles/CMakeScratch/TryCompile-JiULQF/src.cxx")
file(GENERATE OUTPUT "${CMAKE_BINARY_DIR}/cmTC_f4d2a_loc"
CONTENT $<TARGET_FILE:cmTC_f4d2a>)
set_property(TARGET cmTC_f4d2a PROPERTY "CXX_STANDARD" "17")
target_link_libraries(cmTC_f4d2a ${LINK_LIBRARIES})
```
Also compilation line:
```
[1/2] /usr/bin/clang++-14 -DHAVE_ERROR_STOP -std=gnu++17 -MD -MT CMakeFiles/cmTC_f4d2a.dir/src.cxx.o -MF CMakeFiles/cmTC_f4d2a.dir/src.cxx.o.d -o CMakeFiles/cmTC_f4d2a.dir/src.cxx.o -c /home/sashas/workspace/test_proj/cmake-build-debug/CMakeFiles/CMakeScratch/TryCompile-JiULQF/src.cxx
```
Which means that settings of neither CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES nor CMAKE_CXX_STANDARD_LIBRARIES is not respected by the macro.https://gitlab.kitware.com/cmake/cmake/-/issues/24995cmake_print_properties: Support log verbosity2023-06-13T12:11:55-04:00Graham LeBlanccmake_print_properties: Support log verbosityIt would be nice for [`cmake_print_properties()`](https://cmake.org/cmake/help/latest/module/CMakePrintHelpers.html) to support specifying log verbosity level like `message()` does.It would be nice for [`cmake_print_properties()`](https://cmake.org/cmake/help/latest/module/CMakePrintHelpers.html) to support specifying log verbosity level like `message()` does.https://gitlab.kitware.com/cmake/cmake/-/issues/24994Modules: Remove unnecessary check module include statements2023-06-12T15:44:13-04:00Brad KingModules: Remove unnecessary check module include statements!8311 changed the implementation of some check modules to use different check modules as dependencies than they did prior to 3.27. As reported in #24991, that regressed projects that were accidentally relying on indirect inclusion of th...!8311 changed the implementation of some check modules to use different check modules as dependencies than they did prior to 3.27. As reported in #24991, that regressed projects that were accidentally relying on indirect inclusion of those other check modules.
3.27 includes the old check module dependencies only for compatibility with such projects. We may need a policy to remove them.https://gitlab.kitware.com/cmake/cmake/-/issues/24993Better support for directory moves2023-06-12T09:23:50-04:00Eyal Rozenbergeyalroz1@gmx.comBetter support for directory movesI have a project in `/dir1/repo`, and I configure it using `cmake -B build_dir` when in the project root as the. Later, I move the repository (with its build dir) from `/dir1/repo` to `/dir2/repo`. Then, in the project root, I run the co...I have a project in `/dir1/repo`, and I configure it using `cmake -B build_dir` when in the project root as the. Later, I move the repository (with its build dir) from `/dir1/repo` to `/dir2/repo`. Then, in the project root, I run the configure command again (`cmake -B build_dir`). I then get
```
CMake Error: The source "/dir2/repo/build_dir/CMakeLists.txt" does not match the source "/dir2/repo/build_dir/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
Now, sure, I _could_ do that. But - I shouldn't have to. CMake should be able to accept my having moved the directory. Maybe not accept it silently, but either using a prompt or subject to a command-line switch - have the configuration updated instead of just giving up.
As for what that update means - the simplest thing is just reconfigure from scratch, overwriting any existing files. A more complex approach would be keeping the cache, but applying some heuristic to decide which values to keep and which to re-derive.https://gitlab.kitware.com/cmake/cmake/-/issues/24992Language build rules should be changeable target properties instead of global...2023-06-16T10:44:19-04:00Alexander NeumannLanguage build rules should be changeable target properties instead of global platform dependent variables.It would probably make sense to move the build rules (i.e. `CMAKE_${lang}_LINK_EXECUTABLE`, `CMAKE_${lang}_CREATE_(SHARED|STATIC|MODULE)_LIBRARY`, `CMAKE_${lang}_COMPILE_OBJECT` etc) into the targets themselves instead of having purely g...It would probably make sense to move the build rules (i.e. `CMAKE_${lang}_LINK_EXECUTABLE`, `CMAKE_${lang}_CREATE_(SHARED|STATIC|MODULE)_LIBRARY`, `CMAKE_${lang}_COMPILE_OBJECT` etc) into the targets themselves instead of having purely global rules.
From what those variables do it should already be clear that they only make sense if they are directly associated with certain targets instead of being globally defined. The global definition however could easily be the default like many other `CMAKE_` variables for target properties.
Use case:
I had at least one target in a MSVC toolchain where I ~~wanted~~ needed to invoke the compiler instead of linker for linking.https://gitlab.kitware.com/cmake/cmake/-/issues/24990`CMAKE_LINKER` does not do what it is thought to do2023-10-16T10:39:54-04:00Cristian Le`CMAKE_LINKER` does not do what it is thought to doIntuitively when one sets `CMAKE_LINKER`, one expects that it will be used as the default linker for all languages. But that's not true because the toolchains prefer to use the compiler for the linker. Thus one has to define the linker l...Intuitively when one sets `CMAKE_LINKER`, one expects that it will be used as the default linker for all languages. But that's not true because the toolchains prefer to use the compiler for the linker. Thus one has to define the linker liker by setting linker flags like `-fuse-ld=lld`.
It would be preferred instead if the toolchain files can check `CMAKE_LINKER` and automatically add the appropriate flag for the compiler to use what linker was specified there.
Edit: I wanted to add some reference about `CMAKE_LINKER` documentation, but I do not see any. I don't remember where I originally got the impression of using that variable (maybe from the CMakeCache.txt?). Is there some history around that variable?