CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-04-15T07:33:51-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/23425Makefiles: incorrect/missing dependencies when using symbolic links2022-04-15T07:33:51-04:00Deliciously TypedMakefiles: incorrect/missing dependencies when using symbolic links**Symptom:**
After the initial cmake generation and build of my code set, subsequent make invocations would continue to always rebuild what coincidentally happened to be the most time-consuming target, so I started looking into the issu...**Symptom:**
After the initial cmake generation and build of my code set, subsequent make invocations would continue to always rebuild what coincidentally happened to be the most time-consuming target, so I started looking into the issue.
**Discussion/Recommendation:**
(Note: despite the wall of text that it took to find it, the actual issue appears pretty simple.)
Why do you even touch the `.d` output of the compiler instead of directly transplanting the paths into what I assume is supposed to be some sort of cache or such? This leads to precisely these kinds of semantic mismatch issues, instead of doing whatever the compiler does, which instead of replicating the logic, should be left to the compiler anyway - since it's the one that generated the files in the first place, and knows better?
**If it's possible that this is a recurring problem with the many uses of this path handling code in the codebase, perhaps another issue should be opened for tracking fixing this in other occurrences as well?**
**Diagnosis:**
After difficulties finding any useful information in the make -d output, about what was forcing a rebuild of the target in question, I switched to using remake (https://github.com/rocky/remake) which is a make fork that has much better inspection capabilities.
The log output of `remake -d --trace` contained:
```
CMakeFiles/main_chapter0_prog1.dir/build.make:89: update target 'CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/main.cpp.o' due to: /<shortened>/4_prog1/include/std_lib_facilities.h /<shortened>/4_prog1/include/_std_lib_facilities.h
```
This is a nonexistent path. The correct path is `/<shortened>/4_prog1/ppp/include/std_lib_facilities.h` ; note the `ppp` which can be observed in other paths. The correct path is in this case accessed by the following code, which I was experimenting with:
```
// include hack https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
//TODO test both branches
#if defined __has_include
# if __has_include ("../../../include/std_lib_facilities.h")
// include "../../../include/std_lib_facilities.h"
# else
# include "../../../../include/std_lib_facilities.h"
# endif
#else
#error "__has_include not supported when including std_lib_facilities wrapper in >TODO<"
#endif
```
Note that the nature of this code is not actually relevant, this is just to show a bit better what I had set up here.
Note that one of the preprocessor branches is commented out, so there is only one actual branch in use.
This code is supposed to import the header via the path: `/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/../../../../include/std_lib_facilities.h`.
Further investigation by grep shows that the incorrect header location only shows up in these files, and only after the original generation and build, when a second build is attempted:
```
$ grep -irl /<shortened>/4_prog1/include/std_lib_facilities.h
CMakeFiles/main_chapter0_prog1.dir/compiler_depend.make
CMakeFiles/main_chapter0_prog1.dir/compiler_depend.internal
```
After numerous false starts involving strace-ing to attempt to find what causes the incorrect lines to be written and what writes the compiler_depend files, and looking at gcc -MD/-MF/whatever invocations that generate obviously correct dynamic .d dependency files (which contain the _correct_ include path) that are included by make, a friend unstuck me in the debug process and I figured out the rest of the issue:
It was a this point that I realized/it was pointed out to me that the faulty path had exactly the number of path components removed as there were `..` components, instead of interpreting symbolic links. At this point it can be assumed that the behaviour is caused by simply interpeting paths as strings instead of trying to resolve anything.
From previous strace output observation (PID write()s to relevant file or something) I found a variant of the command below, and one assumes it has something to do with the compiler_depend files. I don't remember how I found the execve line for it exactly, but in the knowledge that make must somehow invoke cmake, I found this command line via grep:
```
$ grep -irl cmake_depends
CMakeFiles/main_chapter0_prog1.dir/build.make
CMakeFiles/main_chapter0_prog1.dir/DependInfo.cmake
```
, where `build.make` contains among other things, the following:
```
CMakeFiles/main_chapter0_prog1.dir/depend:
cd /<shortened>/4_prog1/ppp/infra/build && $(CMAKE_COMMAND) -E cmake_depends "Unix Makefiles" /<shortened>/4_prog1/ppp/infra /<shortened>/4_prog1/ppp/infra /<shortened>/4_prog1/ppp/infra/build /<shortened>/4_prog1/ppp/infra/build /<shortened>/4_prog1/ppp/infra/build/CMakeFiles/main_chapter0_prog1.dir/DependInfo.cmake --color=$(COLOR)
```
The cmake_depend 'command mode' appears to be undocumented beyond some StackOverflow questions.
On this command line we can also see a mention of the `DependInfo.cmake` file, which also sounds relevant.
Looking at the `DependInfo.cmake` file we find the following:
```
<omitted>
# The set of dependency files which are needed:
set(CMAKE_DEPENDS_DEPENDENCY_FILES
"/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp" "CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp.o" "gcc" "CMakeFiles/main_chapter0_prog1.dir/<shortened>/4_prog1/ppp/prog1/chapter0/GUI/GUI.cpp.o.d"
<omitted> )
<omitted>
```
Searching Google for `CMAKE_DEPENDS_DEPENDENCY_FILES` leads to https://github.com/Kitware/CMake/blob/master/Source/cmLocalUnixMakefileGenerator3.cxx , which looks relevant, so I started digging in here at this point.
Given the name, contents, and invocation, this is probably the code that either writes, or causes something else to write the faulty include path.
This is where I finally find what I'm looking for:
https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmLocalUnixMakefileGenerator3.cxx#L1429
A few lines below mentions can be found of `compiler_depend.make` and `compiler_depend.internal`:
https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmLocalUnixMakefileGenerator3.cxx#L1434
After inspecting this area of the function, and the called functions, it can be seen that the `CheckDependencies` function is what actually creates the dependency entries to be written out later. The definition is located in https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmDependsCompiler.cxx#L29
My compiler is gcc so either this, or the `'custom'` branch handle it; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmDependsCompiler.cxx#L139
Through the gcc `.d` file handling code, this eventually invokes the `cmSystemTools::CollapseFullPath` function; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/cmGccDepfileReader.cxx#L41
This is implemented in `CollapseFullPathImpl`: https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/kwsys/SystemTools.cxx#L3467 , which calls `SystemToolsAppendComponents`; https://gitlab.kitware.com/cmake/cmake/-/blob/56dafdf19906bc19c5f90c0ea8ede02c3b44958b/Source/kwsys/SystemTools.cxx#L3442
**This is the code that, as can be seen, indeed does the naive relative path compression, and is the root cause of this problem.** (Well, I imagine. I haven't tried recompiling CMake with a dirty hack of a patch.)https://gitlab.kitware.com/cmake/cmake/-/issues/23876Makefiles: Multiple targets not built in parallel2022-09-01T11:49:03-04:00Jonathan SweemerMakefiles: Multiple targets not built in parallelIf I specify multiple `--target` flags on the command line along with `--parallel`, the targets are built sequentially, not in parallel.
For example, if I have the following CMakeLists.txt file:
```cmake
cmake_minimum_required(VERSION ...If I specify multiple `--target` flags on the command line along with `--parallel`, the targets are built sequentially, not in parallel.
For example, if I have the following CMakeLists.txt file:
```cmake
cmake_minimum_required(VERSION 3.24.0)
project(parallel-test LANGUAGES CXX)
add_executable(a a.cpp)
add_executable(b b.cpp)
```
Then the following command runs sequentially.
```console
$ cmake .
$ cmake --build . --target a --target b --parallel
[ 50%] Building CXX object CMakeFiles/a.dir/a.cpp.o
[100%] Linking CXX executable a
[100%] Built target a
[ 50%] Building CXX object CMakeFiles/b.dir/b.cpp.o
[100%] Linking CXX executable b
[100%] Built target b
```
But if I omit the `--target` flags then the project is indeed built in parallel.
```console
$ cmake --build . --parallel
[ 25%] Building CXX object CMakeFiles/a.dir/a.cpp.o
[ 50%] Building CXX object CMakeFiles/b.dir/b.cpp.o
[ 75%] Linking CXX executable b
[100%] Linking CXX executable a
[100%] Built target b
[100%] Built target a
```
Can CMake be changed to build targets in parallel in the first case as well?
CMake version: 3.24.1
OS version: Ubuntu 18.04.6 LTShttps://gitlab.kitware.com/cmake/cmake/-/issues/15859Makefiles: Problems in Windows related to maximum path length2023-06-01T11:55:44-04:00Kitware RobotMakefiles: Problems in Windows related to maximum path lengthThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15859). Further discussion may take place here.
---
I use cmake to generate "nmake Makefiles" in Windows (Visual Studio
compile...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15859). Further discussion may take place here.
---
I use cmake to generate "nmake Makefiles" in Windows (Visual Studio
compiler). The project is rather large, hence, I tend to run into max
path limitation problems.
I have understood that I should not run into these problems since the
hashing of the paths is intended to cope with most of these problems.
I have then downloaded the latest version of the cmake source code and
found the reason for this problem:
Let us assume we have defined a project XX which defines two targets
1. "XX"
2. "XX_variant1_with_modification_a"
which, e.g., are shared libraries.
I use very long path names and run into the system maximum path
limitations. I understood that the maximum path length is 250 on Windows
and leads to the shortened version of the object paths in case the path
turns out to be too large. The shortening is based on the MD5 hashing
mechanism.
I found that the object filename shortening happens in file
"cmLocalGenerator.cxx". In that function, all object file lengths are
checked against the maximum path
length given. The function declaration is "bool
cmLocalGeneratorCheckObjectName(std::string& objName,
std::string::size_type dir_len, std::string::size_type max_total_len)",
the object file path is characterized by the "dir_len" and the
"objName", the path limitation is specified by "max_total_len".
In the path length comparison, the "dir_len" value comes from an
evaluation of the variable "dir_max" which originates from
a function called void
"cmLocalUnixMakefileGenerator3::ComputeObjectFilenames(std::map<cmSourceFile
const*, std::string>& mapping,cmGeneratorTarget const* gt)
in "cmLocalUnixMakefileGenerator3.cpp" (involving functions
"CreateSafeUniqueObjectFileName" and "GetObjectFileNameWithoutTarget").
As far as I understood, the variable "dir_max" and with it value of
"dir_len" are incorrect: Coming back to our situation with the two
targets which
are derived from the project name, cmake generates object files in
subfolders of "<path-to-XX>/CMakeFiles/XX.dir" and
"<path-to-XX>/CMakeFiles/XX_variant1_with_modification_a.dir". In the
function "cmLocalGeneratorCheckObjectName",
however, the variable "dir_len" is related to a value of "dir_max" which
corresponds to the "<path-to-XX>/CMakeFiles/XX.dir".
This is not the maximum directory length as would be expected: In my
opinion, the value of "dir_max" should be
"<path-to-XX>/CMakeFiles/XX_variant1_with_modification_a.dir"!
If an object filename meets the constraints given the directory
"<path-to-XX>/CMakeFiles/XX.dir" to not cause the filename shortening,
it may happen that the path is too long for the directory
"<path-to-XX>/CMakeFiles/XX_variant1_with_modification_a.dir".
In the current implementation, the hashing/shortening mechanism is not
triggered, the resulting object file name path is longer than 250 and
I see a hard-to-understand build error.
The conclusion: the variable "dir_max" does not really contain the
maximum length directory name given all targets but only the directory
name of the first target or the project name - i did not follow this in
detail. My solution to overcome this problem currently: I set the
CMAKE_OBJECT_PATH_MAX value to a value lower than 250, e.g.,
set(CMAKE_OBJECT_PATH_MAX 240)
in order to take into account that the maximum target path directory
length is by maximum 10 larger than the project directory path.
https://gitlab.kitware.com/cmake/cmake/-/issues/17791MAKEFLAGS breaks C++11 feature check during bootstrap2018-03-05T16:58:29-05:00David FaureMAKEFLAGS breaks C++11 feature check during bootstrap`export MAKEFLAGS=-j8` breaks cmake's bootstrap, which says
```
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
```
Yes...`export MAKEFLAGS=-j8` breaks cmake's bootstrap, which says
```
-- Checking if compiler supports C++ unique_ptr - no
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
```
Yes this looks completely unrelated, hold on, it will make sense.
The actual output from the try_compile is
```
Run Build Command:"/home/dfaure/bin/gmake" "cmTC_60a44/fast"
gmake -f CMakeFiles/cmTC_60a44.dir/build.make CMakeFiles/cmTC_60a44.dir/build
gmake[1]: warning: -jN forced in submake: disabling jobserver mode.
gmake[1]: Entering directory '/d/kde/build/5/cmake-git/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o
/home/dfaure/bin/g++ -std=gnu++1z -o CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o -c /d/kde/src/5/cmake-git/Source/Checks/cm_cxx_unique_ptr.cxx
Linking CXX executable cmTC_60a44
/d/kde/build/5/cmake-git/Bootstrap.cmk/cmake -E cmake_link_script CMakeFiles/cmTC_60a44.dir/link.txt --verbose=1
/home/dfaure/bin/g++ -rdynamic CMakeFiles/cmTC_60a44.dir/cm_cxx_unique_ptr.cxx.o -o cmTC_60a44
gmake[1]: Leaving directory '/d/kde/build/5/cmake-git/CMakeFiles/CMakeTmp'
```
Notice how the third line has a gmake warning (due to `gmake -f` being called instead of `$(MAKE) -f`).
This triggers the following code in Source/Checks/cm_cxx_features.cmake:
```
# If using the feature causes warnings, treat it as broken/unavailable.
if(check_output MATCHES "[Ww]arning")
set(CMake_HAVE_CXX_${FEATURE} OFF CACHE INTERNAL "TRY_COMPILE" FORCE)
endif()
```
So the make warning is treated as a compiler warning ;-)
I've been trying to find the "proper" fix for this ($(MAKE) instead of gmake), but I can't find where that comes from.
Source/cmLocalUnixMakefileGenerator3.cxx does say $(MAKE)...
Version: cmake git, release branch. git describe says `v3.11.0-rc2`.https://gitlab.kitware.com/cmake/cmake/-/issues/18655Managed C++ assembly for Visual Studio 20082018-11-28T14:34:37-05:00Mr-QuestionManaged C++ assembly for Visual Studio 2008There is a project that must be compiled using Visual Studio 2008 due to compatibility reasons.
Having pleasant experience with elder versions of VS, I would prefer to use CMake for that project (it can improve usability and save a lot o...There is a project that must be compiled using Visual Studio 2008 due to compatibility reasons.
Having pleasant experience with elder versions of VS, I would prefer to use CMake for that project (it can improve usability and save a lot of time).
However, it seems there is no support for this one, according to documentation.
Is it possitle to do it using the latest CMake?
If no, do you have plans to add support for mixed "C++ - C++/CLI - C#" projects for VS 2008 in further?https://gitlab.kitware.com/cmake/cmake/-/issues/20440MAP_IMPORTED_CONFIG is hard to use and not documented well enough2020-03-13T11:12:54-04:00Stephen KellyMAP_IMPORTED_CONFIG is hard to use and not documented well enoughThe RelWithDebInfo configuration is required in order to perform profiling.
When using an external SDK which provides debug and release variants of libraries, the release variant of libraries should be used in the relwithdebinfo configu...The RelWithDebInfo configuration is required in order to perform profiling.
When using an external SDK which provides debug and release variants of libraries, the release variant of libraries should be used in the relwithdebinfo configuration. Otherwise (at least on Windows often) link errors result.
The `MAP_IMPORTED_CONFIG_<CONFIG>` target property is provided to allow mapping a configuration `CFG` to a location `IMPORTED_LOCATION_${CFG}`, such as from `RelWithDebInfo` configuration to the `IMPORTED_LOCATION_RELEASE`.
1)
It is not entirely clear whether it is the responsibility of the SDK authors to implement that mapping in config-file packages, or the responsibility of the consumer to map all of their third party dependencies properly. I suspect the former should be true, however the `MAP_IMPORTED_CONFIG_*` properties are not exported when cmake creates `IMPORTED` targets with `install(EXPORT)`, so this is not currently implemented simply. Some buildsystems in the wild attempt to implement this externally: https://codereview.appspot.com/6670043/ . It may be by-design that only project code sets these properties: https://gitlab.kitware.com/cmake/cmake/issues/16091 .
CMake should possibly document where the responsibility to set `MAP_IMPORTED_CONFIG_<CONFIG>` lies and create simpler API for implementing it from the SDK if it should be set from there. Even if an SDK only sets the mappings for configs that it knows about, that would not prevent third parties from implementing mappings for custom configurations.
2)
The somewhat non-intuitive behavior shown here is not documented:
https://cmake.org/pipermail/cmake-developers/2015-July/025843.html
This may or may not be worth documenting.
3) The seemingly most-common usecase of mapping relwithdebinfo to release is not well-addressed. It seems to be a common pitfall: https://gitlab.kitware.com/cmake/cmake/issues/20319
The trick/requirement to reorder configurations in `IMPORTED_CONFIGURATIONS` is not documented: https://gitlab.kitware.com/cmake/cmake/issues/16091
Indeed, the order of entries in `IMPORTED_CONFIGURATIONS` is not well-defined by the main config-file package generated by `install(EXPORT)`.
4) It is practical for projects to want to map relwithdebinfo to release using
```
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
```
and the existing documentation suggests that would be appropriate, but it does not work when some external dependencies (possibly from different third party SDKs) set only the non-config `IMPORTED_LOCATION` property. In that case, a confusing error such as
```
ninja: error: 'thirdparty::somelib-NOTFOUND', needed by 'consumer', missing and no known rule to make it
```
is issued.
To make that usecase work, something like
```
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO "" RELEASE)
```
is needed. This also appears here:
* https://github.com/microsoft/vcpkg/pull/6393
* https://gitlab.kitware.com/cmake/cmake/issues/18134
----
----
At least the documentation of this property could be improved to better address the common use-cases, but the design ideas in https://gitlab.kitware.com/cmake/cmake/issues/20319 could also be worth exploring.
The attached project demonstrates the issue and starts to approximate an auto-test.
[configmap.tar.gz](/uploads/5dd2e6c7a8c1123531af991f29d5a6ec/configmap.tar.gz)https://gitlab.kitware.com/cmake/cmake/-/issues/18280Marking as advanced in bulk based on directory2023-11-03T17:38:44-04:00Robert DaileyMarking as advanced in bulk based on directoryIt would be great to have a setting that, if set to ON, defaults new cache variables appearing after it to ADVANCED. When setting it back to OFF, this disables the feature. The use case for this is when I use `add_subdirectory()` to pull...It would be great to have a setting that, if set to ON, defaults new cache variables appearing after it to ADVANCED. When setting it back to OFF, this disables the feature. The use case for this is when I use `add_subdirectory()` to pull in third party submodules with CMake projects into my own. I do not want settings & cache variables to be listed in the GUI. The user should not control these libraries with settings, I make sure settings are explicitly set prior to doing `add_subdirectory()`. I want to be able to mark configuration added by that library as advanced without having to care about the CMake code.
Right now I have to use the `mark_as_advanced()` command on individual cache entries to hide them. This is error prone and high maintenance since if I upgrade that library, and they change their configuration variables, I have to make sure that list is updated.
Example of what I'd like:
```
set( CMAKE_MARK_AS_ADVANCED ON )
add_subdirectory( ThirdPartyLibrary )
```
Or:
```
set_property( DIRECTORY PROPERTY MARK_AS_ADVANCED ON )
add_subdirectory( ThirdPartyLibrary )
```https://gitlab.kitware.com/cmake/cmake/-/issues/18529Matlab_UT_LIBRARY missing in FindMatlab package2018-10-31T12:13:58-04:00Andreas MartinMatlab_UT_LIBRARY missing in FindMatlab packageI have to link the libut library to my project. With MATLAB R2017b, MSVC2015 and Windows7 64bit I have to do a workaround:
```
# Find MATLAB
set( MATLAB_FIND_DEBUG 1 )
find_package( Matlab REQUIRED COMPONENTS MX_LIBRARY )
# Add libut lib...I have to link the libut library to my project. With MATLAB R2017b, MSVC2015 and Windows7 64bit I have to do a workaround:
```
# Find MATLAB
set( MATLAB_FIND_DEBUG 1 )
find_package( Matlab REQUIRED COMPONENTS MX_LIBRARY )
# Add libut library
get_filename_component( Matlab_MX_LIBRARY_PATH ${Matlab_MX_LIBRARY} DIRECTORY )
find_library( Matlab_UT_LIBRARY NAME libut.lib libut.so HINT ${Matlab_MX_LIBRARY_PATH} )
target_link_libraries( <TARGET> ${Matlab_UT_LIBRARY} )
```
This works so far for Windows and linux, but probably there is a more shorthand solution..?
Regards,
Andreashttps://gitlab.kitware.com/cmake/cmake/-/issues/18441mechanism to set msbuild properties on source file's <ClCompile> node?2018-10-11T14:39:22-04:00Kevin Puetzmechanism to set msbuild properties on source file's <ClCompile> node?There doesn't seem to be a way to specify msbuild properties per-source like there is for global ones.
I have a test project for a header-only library with a corresponding test project that wants to "compile" a number of files with `-...There doesn't seem to be a way to specify msbuild properties per-source like there is for global ones.
I have a test project for a header-only library with a corresponding test project that wants to "compile" a number of files with `-Zs` or `-fsyntax-only`, to test the template logic without actually producing an executable. I've structured this as an OBJECT library that nobody actually links in, which works well just using target_compile_options to add the relevant flags, except for the Visual Studio (.vcxproj) generator (it works fine with MSVC if using makefiles or ninja).
The problem is that, despite being an OBJECT library, CMake's .vcxproj generator still emits `<ConfigurationType>StaticLibrary</ConfigurationType>`, thus msbuild tries to call lib.exe to assemble the .lib files. Due to using `-Zs`, there aren't any object files for it to consume.
Microsoft.Cpp.targets does have a means to express that a compile doesn't yield anything that goes into the .lib archive, namely
```
<ClCompile Include="path/to/foo.h">
<LibCompiled>false</LibCompiled>
</ClCompile>
```
See also: https://github.com/Microsoft/msbuild/issues/415 (which isn't me, just something relevant I turned up while searching).
But CMake doesn't seem to have any way to generate that property.
targets have `set_property(TARGET <target> PROPERTY VS_GLOBAL_<variable> <value>)`, but that can't set things inside <ClCompile>, or on per-source options.
But that suggests one solution could be an analogous `set_property(SOURCE foo.c PROPERTY VS_CLCOMPILE_<variable> <value>)`, with any the options thus provided just added into `clOptions.AddFlag(<variable>,<Value>)` during cmVisualStudio10TargetGenerator::OutputSourceSpecificFlags.https://gitlab.kitware.com/cmake/cmake/-/issues/15159MemCheck & CDash: timeout reported as "failed" instead of "timeout"2018-02-21T09:08:47-05:00Kitware RobotMemCheck & CDash: timeout reported as "failed" instead of "timeout"This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15159). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15159). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15158MemCheck: Valgrind with multiple supressions files2018-04-28T09:16:21-04:00Kitware RobotMemCheck: Valgrind with multiple supressions filesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15158). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15158). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/16448MemCheckType of UndefinedBehaviorSanitizer fails without an (empty) CTestCust...2019-07-21T07:21:22-04:00Dave RigbyMemCheckType of UndefinedBehaviorSanitizer fails without an (empty) CTestCustom.cmake fileWhen trying to use CMake/CTest to run tests under UndefinedBehaviourSanitizer, it fails with the following message if no `CTestCustom.cmake` file exists:
```
$ ctest -D ExperimentalMemCheck
Site: mancouch
Build name: Linux-clang+...When trying to use CMake/CTest to run tests under UndefinedBehaviourSanitizer, it fails with the following message if no `CTestCustom.cmake` file exists:
```
$ ctest -D ExperimentalMemCheck
Site: mancouch
Build name: Linux-clang++-3.8
Memory check project /home/daver/repos/couchbase/server/build-ubsan/ep-engine
Memory checker (MemoryCheckCommand) not set, or cannot find the specified program.
Errors while running CTest
```
By creating a `CTestCustom.cmake` - even an empty one - the problem goes away.
Discussion on #cmake on IRC identified the issue:
```
[09:19:16] <Dave_R> Hi All. I'm trying to setup CMake/CTest to drive the UndefinedBehavior memory checker (added here: https://gitlab.kitware.com/cmake/cmake/commit/816c100ae2d1ef9ad42186a260724a279b6b5934). However when I SET(MEMORYCHECK_TYPE UndefinedBehaviorSanitizer), I get "error: Memory checker (MemoryCheckCommand) not set, or cannot find the specified program." Any suggestions?
[09:19:26] <Dave_R> (This is with cmake 3.5.1)
[09:41:34] <Dave_R> ok, getting a bit further - issue is that there's no "CMakeCommand" option in my CMake-generated DartConfiguration.tcl. If I manaully add one it works
[09:41:53] <Dave_R> Anyone know how I can get CMake to add this option to the CTest config file it generates?
[09:52:03] <ngladitz> Dave_R: I think ctest itself is supposed to set it
[09:52:43] <Dave_R> ngladitz I've got a as far a gdb'ing ctest at that point, and indeed the CTest object has it as a blank string :(
[09:54:21] <ngladitz> hm it looks like the code that sets "CMakeCommand" is conditional
[09:54:55] <ngladitz> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestMemCheckHandler.cxx#l278
[09:55:33] <ngladitz> I think it only gets run when you have a CTestCustom.cmake
[09:55:56] <Dave_R> ngladitz ah yes. Let me see if I'm hitting that...
[09:56:14] <ngladitz> an empty CTestCustom.cmake would probably suffice
[09:56:17] <Dave_R> ok, so that method is not getting executed on my run
[09:56:20] <Dave_R> ok, let me try that
[09:56:27] <Dave_R> in the build directory?
[09:56:49] <ngladitz> yes
[09:57:05] <Dave_R> aha - victory!
[09:57:20] <Dave_R> thanks for your help
```https://gitlab.kitware.com/cmake/cmake/-/issues/25206Memory leak in function archive_read_open_filename_w2023-08-25T11:05:34-04:00Hayk AslanyanMemory leak in function archive_read_open_filename_w<!--
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/
-->
Memory leak in function `archive_read_open_filename_w`.
A memory leak is reported by a static analyzer tool developed at CAST (https://www.linkedin.com/company/cast-center).
Specifically, dynamic memory is allocated in Utilities/cmlibarchive/libarchive/archive_read_open_filename.c:162 and is freed, or copied under custom conditions.
If conditions until line 207 are not satisfied the memory leak will accure. As archive_read_append_callback_data function can return ARCHIVE_FATAL in several cases, the condition in line 205 can be unsatisfied.
Allocated memory should be freed in those cases.https://gitlab.kitware.com/cmake/cmake/-/issues/24826message(): select default mode through a variable2023-04-19T12:09:54-04:00Valerio Di Leccemessage(): select default mode through a variableIn my experience, I have invoked the `message()` command for general messages with mode STATUS 95% of the time. Emitting many messages might get verbose as the project grows.
I think it would be nice to have a variable, say `CMAKE_MESSA...In my experience, I have invoked the `message()` command for general messages with mode STATUS 95% of the time. Emitting many messages might get verbose as the project grows.
I think it would be nice to have a variable, say `CMAKE_MESSAGE_DEFAULT_MODE`, to specify the default mode for the subsequent `message()` calls not providing an explicit mode. Since currently the mode is optional (corresponding to `NOTICE`), the new variable could be empty by default for backwards compatibility. The `message()` command could default to empty mode if the new variable is set to an invalid mode.
Example:
```cmake
message("This message is emitted as NOTICE")
message(WARNING "This message is emitted as WARNING")
set(CMAKE_MESSAGE_DEFAULT_MODE "STATUS")
message("This message is emitted as STATUS")
message(WARNING "This message is emitted as WARNING")
set(CMAKE_MESSAGE_DEFAULT_MODE "NOT_VALID")
message("This message is emitted as NOTICE")
```https://gitlab.kitware.com/cmake/cmake/-/issues/25659message: Allow choosing output stream (stdout vs stderr) regardless of mode /...2024-02-06T09:10:33-05:00alcroitomessage: Allow choosing output stream (stdout vs stderr) regardless of mode / levelWhen using cmake's script mode (`-P`) as a general scripting language, it would be useful to choose which output stream (`stderr` or `stdout`) messages should be printed to, regardless of message level (`STATUS`, `NOTICE`, etc.)
If one ...When using cmake's script mode (`-P`) as a general scripting language, it would be useful to choose which output stream (`stderr` or `stdout`) messages should be printed to, regardless of message level (`STATUS`, `NOTICE`, etc.)
If one wishes to print to `stdout`, they are forced to choose between `STATUS` to `TRACE`, but those also get the `--` prefix, which might be undesirable.
`message(NOTICE)` doesn't print the `--` prefix, but it goes to `stderr` instead.
Perhaps we can have a new signature, something like:
```
message(PRINT "message text" ... ECHO [stdout | stderr])
```
with a default to stdout.https://gitlab.kitware.com/cmake/cmake/-/issues/22450message: color output on Windows2021-07-21T11:33:46-04:00Brad Kingmessage: color output on Windows!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be neede...!6105 added `message()` color by message type, resolving #16183. However, it was reverted on Windows by !6369 due to #22444, and especially https://gitlab.kitware.com/cmake/cmake/-/issues/22444#note_987530. A new approach will be needed to print color output on Windows while also preserving LF newlines and console encoding conversion.https://gitlab.kitware.com/cmake/cmake/-/issues/16465message: error for chinese on windows2017-10-13T13:17:55-04:00chai2010message: error for chinese on windowscmake version 3.7.0
`message("中文")`
output:
```
涓枃
```cmake version 3.7.0
`message("中文")`
output:
```
涓枃
```https://gitlab.kitware.com/cmake/cmake/-/issues/24615message: Support for Printing Multiple Messages to a Single Line2023-03-20T13:32:26-04:00David Hintonmessage: Support for Printing Multiple Messages to a Single Line<!--
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/
-->
## Summary/Story
I want to be able to print multiple output statements using individual commands on a single line during CMake configuration.
## Version
Windows 10 - CMAKE 3.23.2 - GUI Console/Command Line
## Example
CMake Code:
```
message(STATUS "Hello, ")
# ... Do other arbitrary configuration
message(STATUS "World!")
```
Result:
```
Hello,
World!
```
Desired Result:
```
Hello, World!
```
## Alternative 1
```
execute_process(COMMAND ${CMAKE_COMMAND} -E echo -n "Hello, ") # `-n` echo option is not currently supported
# ... Do other arbitrary configuration
execute_process(COMMAND ${CMAKE_COMMAND} -E echo "World!")
```
Desired Result:
```
Hello, World!
```
## Alternative 2
This is more specific, but it could be nice:
```
message(CHECK_START "Hello, ")
# ... Do conditional configuration
message(CHECK_PASS " World!")
```
Result:
```
Hello,
Hello, - World!
```
Desired Result:
```
Hello, - World!
```
* (or simply `Hello, World!`)
## Insights
There may be a way to achieve this already on Linux/Unix-like shell, i.e.:
```
execute_process(COMMAND bash "-c" "echo -n Hello, World!")
```
but I am looking for a native, convenient option.
My example here is of course trivial, but in reality I'm dealing with many thousands of lines of configuration output, many of them are similar in sequence and it is much easier to see patterns in output when similar output messages (looping) are on a single line. By adding support for this, I can essentially create a table of output which will greatly help me to optimize/improve/debug the CMake configuration for a very large software suite I am supporting.
## Reference
Here are a few sources that I referenced while attempting to get something working.
* https://stackoverflow.com/questions/51040536/how-to-print-without-newline-in-cmake/75770357#75770357
* https://stackoverflow.com/questions/24967260/c-remove-a-newline-character-that-has-already-been-printed
* https://unix.stackexchange.com/questions/167798/how-to-append-line-to-previous-line
* https://www.howtogeek.com/446071/how-to-use-the-echo-command-on-linux/
* https://stackoverflow.com/questions/35689501/cmakes-execute-process-and-arbitrary-shell-scripts#35695350https://gitlab.kitware.com/cmake/cmake/-/issues/25062Messy interactions between ExternalProject_Add and cmake -E tar and documenta...2023-07-07T04:24:40-04:00Cristian Morales VegaMessy interactions between ExternalProject_Add and cmake -E tar and documentation issuesI have a ExternalProject_Add(... URL http://host/file.deb).
A problem is that, even if you specify DOWNLOAD_NAME, it's ignored. This is because it's first set (https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf09...I have a ExternalProject_Add(... URL http://host/file.deb).
A problem is that, even if you specify DOWNLOAD_NAME, it's ignored. This is because it's first set (https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf0924e3dc4686/Modules/ExternalProject.cmake#L2761), but then overwritten by https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf0924e3dc4686/Modules/ExternalProject.cmake#L3053. So, no matter what you do, unless DOWNLOAD_NO_EXTRACT is used, the file is always going to be named "archive.tar".
No big deal, you would say. Unless the file matches one of the supported format (https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf0924e3dc4686/Modules/ExternalProject.cmake#L3042), the extraction would fail anyway.
The extraction is done with cmake -E tar (https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf0924e3dc4686/Modules/ExternalProject/extractfile.cmake.in#L32) and a deb file is a https://www.man7.org/linux/man-pages/man1/ar.1.html file, which is not supported by cmake -E tar (https://cmake.org/cmake/help/latest/manual/cmake.1.html#run-a-command-line-tool -> `Create or extract a tar or zip archive`). But actually, "cmake -E tar" is able to extract the contents of that .deb file.
So
- ExternalProject_Add acts in a surprising way
- The documentation of cmake -E tar is incomplete
Notice that https://gitlab.kitware.com/cmake/cmake/-/blob/fbea5d9f9945363f35aa16c3edcf0924e3dc4686/Modules/ExternalProject.cmake#L3042 also mentions the "7z" extension. I have not tested it but, if it's supported, `Create or extract a tar or zip archive` also fails to mention it.
And by this point, you start to wonder whether "tar" is the best name for a command able to handle so much more than tars.https://gitlab.kitware.com/cmake/cmake/-/issues/21668MIDL: Control over TLB output directory2021-01-06T10:48:27-05:00matkaraMIDL: Control over TLB output directoryWhen adding a IDL file to a windows ATL library, it is not obvious how we can control where the TLB file will be written.
TLB files are deployed to be used by the library consumers in their own IDL files, or in c++ through `#import "fil...When adding a IDL file to a windows ATL library, it is not obvious how we can control where the TLB file will be written.
TLB files are deployed to be used by the library consumers in their own IDL files, or in c++ through `#import "file.tlb" no_registry`.
By default the TLB file is generated in `${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}.dir/$<CONFIG>`. We would like to redirect the default TLB output directory to the custom directory, without using a custom command call to midl.
I tried approaches such as :
```cmake
file(TO_NATIVE_PATH NATIVE_TLB_OUT ${TARGET_TLB_DIR})
file(CONFIGURE OUTPUT midl_options.txt CONTENT "/out @NATIVE_TLB_OUT@")
set_source_files_properties(${IDL_FILE} PROPERTIES COMPILE_OPTIONS "/MIDL:midl_options.txt /TLBOUT:${NATIVE_TLB_OUT}")
set_source_files_properties(${IDL_FILE} PROPERTIES LINK_OPTIONS "/MIDL:midl_options.txt /TLBOUT:${NATIVE_TLB_OUT}")
```
But it did not help.
- Is there a way to control the MIDL output directory?
- Is there a way to control the MIDL options through cmake without making a custom command calling directly midl?
There seems to be the location of the cmake source code :
![image](/uploads/72c95a99fd089a5ebf6bfdf76bfcac37/image.png)