CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-07-11T05:35:18-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16689Can't set properties of reference assemblies using new CSharp support in CMak...2017-07-11T05:35:18-04:00Don BiglerCan't set properties of reference assemblies using new CSharp support in CMake 3.8Just finished porting VS CSharp solution to CMake 3.8 build system. Works fairly well except for Interop reference assemblies that must be embedded (like Microsoft.Office.Interop.Excel). The reference assembly can be added but there is n...Just finished porting VS CSharp solution to CMake 3.8 build system. Works fairly well except for Interop reference assemblies that must be embedded (like Microsoft.Office.Interop.Excel). The reference assembly can be added but there is no way to enable the "Embed Interop Types" and "Specific Version" properties for the added Interop reference assembly. This results in build errors for CSharp applications that require this feature.Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16688Windows: Warn when TEMP directory is not writable2017-10-13T13:17:55-04:00Dan KegelWindows: Warn when TEMP directory is not writableA trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to...A trivial C project configured fine on all my boxes but one, where cmake complained
```No CMAKE_C_COMPILER could be found``` and ```No CMAKE_CXX_COMPILER could be found```
CMakeError.log showed the compiler id check program failed to
compile; it was located in c:\windows\temp. I looked there, and found
I couldn't even read that directory. Executing
```cacls C:\Windows\Temp /E /G everyone:F```
as administrator made the pain go away.
IIRC CMakeError.log also contained the odd message
```error MSB4036: The "SetEnvironmentVariable" task was not found.```
which may be another telltale for this problem.
Suggestion: when issuing the error "No CMAKE_C_COMPILER could be found" on windows, consider hinting to the user that making c:\windows\temp writeable may help?
This was with Windows 10, Visual Studio 2015, and several versions of cmake (3.6.2 to the latest release). I think I've seen it before with older versions of Visual Studio in the past.https://gitlab.kitware.com/cmake/cmake/-/issues/16687find_library: Skip 'lib => lib<arch>' searches if one symlinks the other2017-05-04T16:23:48-04:00Brad Kingfind_library: Skip 'lib => lib<arch>' searches if one symlinks the otherThe [FIND_LIBRARY_USE_LIB32_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.html)and [FIND_LIBRARY_USE_LIB64_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS.html) global prope...The [FIND_LIBRARY_USE_LIB32_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB32_PATHS.html)and [FIND_LIBRARY_USE_LIB64_PATHS](https://cmake.org/cmake/help/v3.8/prop_gbl/FIND_LIBRARY_USE_LIB64_PATHS.html) global properties ask [find_library](https://cmake.org/cmake/help/v3.8/command/find_library.html) to look in `lib<arch>` directories automatically before corresponding `lib` directories. However, if `lib<arch>` is just a symlink to `lib` (or vice-versa) then we should skip adding the `lib<arch>` path.
This is important to avoid finding paths that are unnecessarily suffixed with `<arch>` because the symlinks typically exist only to satisfy other software that expects them.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16686Multiple directories handled incorrectly in target_include_directories PUBLIC...2017-05-04T16:23:48-04:00MelMultiple directories handled incorrectly in target_include_directories PUBLIC BUILD_INTERFACEIn my test, I am using generator MSVC 2017. I've used CMake versions 3.7 and 3.8.0-rc1.
This is my test CMakeLists.txt:
``` cmake
cmake_minimum_required( VERSION 3.7 )
project( MyApp LANGUAGES C )
add_library(MyApp myapp.c)
t...In my test, I am using generator MSVC 2017. I've used CMake versions 3.7 and 3.8.0-rc1.
This is my test CMakeLists.txt:
``` cmake
cmake_minimum_required( VERSION 3.7 )
project( MyApp LANGUAGES C )
add_library(MyApp myapp.c)
target_include_directories(MyApp PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>
)
```
The Source Directory: **E:\myapp**
The Binary Directory: **E:\myapp\build**
I expect the include directories to be ``E:\myapp\build;E:\myapp```
Instead, I get ```E:\myapp\E:\myapp\build;E:\myapp;```
The relevant line in MyApp.vcxproj is:
``` xml
<AdditionalIncludeDirectories>E:\myapp\E:\myapp\build;E:\myapp;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
```
[CMakeLists.txt](/uploads/74e017fb7b0821e48970dbca4b65f565/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/16685CMake compiler test disabling is not possible2017-10-13T13:17:55-04:00Miklos PuspanCMake compiler test disabling is not possibleProblems:
1) When failing, it deletes all the information, which prevents us to debug, what went wrong.
2) Sometimes it cannot find a compiler during ZERO_CHECK if one of the .cmake files has been changed.
Is it possible to ma...Problems:
1) When failing, it deletes all the information, which prevents us to debug, what went wrong.
2) Sometimes it cannot find a compiler during ZERO_CHECK if one of the .cmake files has been changed.
Is it possible to make improvements on these areas?
Is it possible to disable compiler test with some configuration?
Thanks in advance,
/Miklos Puspanhttps://gitlab.kitware.com/cmake/cmake/-/issues/16684VS_MOBILE_EXTENSIONS - missing PropertySheets in vcxproj2017-10-13T13:17:55-04:00Tomáš LipovskýVS_MOBILE_EXTENSIONS - missing PropertySheets in vcxprojHi, when I turn on VS_MOBILE_EXTENSIONS_VERSION cmake correctly generates `ImportGroup` element with `ExtensionSDKLocation` for WindowsMobile. This works fine and Extension shows up in Visual Studio, but I cannot include any of header fi...Hi, when I turn on VS_MOBILE_EXTENSIONS_VERSION cmake correctly generates `ImportGroup` element with `ExtensionSDKLocation` for WindowsMobile. This works fine and Extension shows up in Visual Studio, but I cannot include any of header file from this SDK extension.
If I remove extension in VS and add it back, then all includes works. I noticed that vcxproj has slight difference - Cmake generated file does not have `PropertySheet` with `SDKExtensionDirectoryRoot`.
Maybe I did something wrong, but there is no `SDKExtensionDirectoryRoot` string in cmake sources, so I guess it can't work anyway.
Cmake generated:
`` <ImportGroup Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), null, $(ExtensionSDKDirectoryRoot), null))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), null, $(ExtensionSDKDirectoryRoot), null))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>``
VS generated:
`` <ImportGroup Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), null, $(ExtensionSDKDirectoryRoot), null))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), null, $(ExtensionSDKDirectoryRoot), null))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>``
``<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|ARM'">
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|ARM'">
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Release|ARM'">
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='MinSizeRel|ARM'">
<Import Project="$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props" Condition="exists('$([Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformExtensionSDKLocation(`WindowsMobile, Version=10.0.10240.0`, $(TargetPlatformIdentifier), $(TargetPlatformVersion), $(SDKReferenceDirectoryRoot), $(SDKExtensionDirectoryRoot), $(SDKReferenceRegistryRoot)))\DesignTime\CommonConfiguration\Neutral\WindowsMobile.props')" />
</ImportGroup>
``https://gitlab.kitware.com/cmake/cmake/-/issues/16683CMake Can't be used for AIX with GNU ld (cross-compilation)2017-10-13T13:17:55-04:00Byoungchan LeeCMake Can't be used for AIX with GNU ld (cross-compilation)I'm trying to setup AIX cross-compile tool using GCC (4.8) and GNU Binutils (2.24) on Linux Host.
When I Use CMake 2.8,7 (Ubuntu 12.04), it can be used for compile C++ programs without any problems.
However, when I use CMake 3.5.1 (U...I'm trying to setup AIX cross-compile tool using GCC (4.8) and GNU Binutils (2.24) on Linux Host.
When I Use CMake 2.8,7 (Ubuntu 12.04), it can be used for compile C++ programs without any problems.
However, when I use CMake 3.5.1 (Ubuntu 16.04), it can't link C++ Programs.
```
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_49385.dir/link.txt
--verbose=1
/home/leebc/toolchain/aix/gcc4.8/bin/powerpc-ibm-aix5.3.0.0-g++
-Wl,-bnoipath -Wl,-brtl CMakeFiles/cmTC_49385.dir/testCXXCompiler.cxx.o -o
cmTC_49385 -Wl,-blibpath:/usr/lib:/lib
/home/leebc/toolchain/aix/gcc4.8/lib/gcc/powerpc-ibm-aix5.3.0.0/4.8.2/../../../../powerpc-ibm-aix5.3.0.0/bin/ld:
target noipath not found
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_49385.dir/build.make:97: recipe for target 'cmTC_49385'
failed
make[1]: *** [cmTC_49385] Error 1
make[1]: Leaving directory
'/home/leebc/myproj/CMakeFiles/CMakeTmp'
```
If I rollback this [commit](https://github.com/Kitware/CMake/commit/767a7ad9dac20d252e71941b6cf03f123c7c37fc), it works fine. Seems like `bnoipath` flag works only for AIX ld, which cannot be used on cross-compilation.https://gitlab.kitware.com/cmake/cmake/-/issues/16682RPATH exclusion of implicit directories does not consider symlinks2017-05-04T16:23:48-04:00Brad KingRPATH exclusion of implicit directories does not consider symlinksWhen computing the runtime search path to pass to the linker `-rpath` option we automatically filter out directories that are implied by the platform or toolchain. This avoids unnecessary rpath entries that may conflict with the real dy...When computing the runtime search path to pass to the linker `-rpath` option we automatically filter out directories that are implied by the platform or toolchain. This avoids unnecessary rpath entries that may conflict with the real dynamic loader's paths.
However, the filter does not account for differences in directory names due to symbolic links. This can cause undesired rpath entries to be left behind.3.8.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16681Support installing a target multiple times2019-10-07T09:45:52-04:00Ben BoeckelSupport installing a target multiple timesThis is required in order to support installing targets for both an *nix-style SDK and a macOS framework setup.
The following list at least needs to be implemented:
- [ ] a policy for the new behavior;
- [ ] moving install-related ...This is required in order to support installing targets for both an *nix-style SDK and a macOS framework setup.
The following list at least needs to be implemented:
- [ ] a policy for the new behavior;
- [ ] moving install-related properties off of targets and on to install commands:
- `INSTALL_INTERFACE` (this will not be simple :/ );
- `INSTALL_NAME_DIR`;
- `INSTALL_RPATH`;
- `INSTALL_RPATH_USE_LINK_PATH`;
- `IOS_INSTALL_COMBINED` (?);
- [ ] support for exporting a target multiple times.
An alternative would be to, as a post-install step, take a *nix-style SDK install tree and create macOS bundles from them, fixing IDs and such in the process. The exported `targets` files would need massaging as well.https://gitlab.kitware.com/cmake/cmake/-/issues/16680When building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends ...2017-05-04T16:23:48-04:00vshashenkoWhen building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends '../' to the path givenMACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle....MACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle. The 'Resources' value seems to have a special meaning on iOS and the files are actually placed in the bundle root. But if use 'Resources/AnotherFolder', it gets prepended with '../' as well.
I've also found this message in the mailing list describing the same problem: https://cmake.org/pipermail/cmake/2016-August/064125.html3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16679CMake Server doesn't provide information on installed targets2020-10-15T08:34:14-04:00John HughesCMake Server doesn't provide information on installed targetsUse case: I'm using CMake as a slave for a top-level SCons builder, and have written a CMake-Server client in Python.
Unfortunately, there is no information in the code model regarding final installed targets (in the install prefix). Th...Use case: I'm using CMake as a slave for a top-level SCons builder, and have written a CMake-Server client in Python.
Unfortunately, there is no information in the code model regarding final installed targets (in the install prefix). This would be required for a really nice SCons/CMake integration as I intend.Tobias HungerTobias Hungerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16678ExternalProject git checkout fails when tag name matches path name2017-05-04T16:23:48-04:00David GlessnerExternalProject git checkout fails when tag name matches path nameExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate path...ExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Current branch bbb is up to date.
```
The following patch fixed it for me. I didn't look to see if other places needed a `--` separator.
```
--- /usr/share/cmake-3.6/Modules/ExternalProject.cmake 2016-09-07 09:11:58.000000000 -0500
+++ ExternalProject.cmake-3.6 2016-09-23 12:50:09.153230047 -0500
@@ -573,7 +573,7 @@
endif()
execute_process(
- COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag}
+ COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag} --
WORKING_DIRECTORY \"${work_dir}/${src_name}\"
RESULT_VARIABLE error_code
)
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16677Ninja generator does not allow building from subfolders of the build directory2017-05-04T16:23:48-04:00Elvis AngelaccioNinja generator does not allow building from subfolders of the build directoryWith the default Makefile generator is possible to go into any subfolder of the build dir and issue `make` (or `make install`) from there, which results in building only the targets of that subfolder. This is very useful when the project...With the default Makefile generator is possible to go into any subfolder of the build dir and issue `make` (or `make install`) from there, which results in building only the targets of that subfolder. This is very useful when the project is big and it would take too much time to `make` it from the root of the build folder.
This is not the case with the Ninja generator, where only one `build.ninja` is generated, in the root of the build folder (while there is one `Makefile` in each subfolder, with the Makefile generator).
Is this possible to fix this? That would make the Ninja generator perfect for my workflow.https://gitlab.kitware.com/cmake/cmake/-/issues/16676CMake slows down, if variable assignment contains patterns with "@"2017-05-04T16:23:48-04:00Martin SchröderCMake slows down, if variable assignment contains patterns with "@"Hi everyone.
We've discovered an issue with CMake's handling of large string constants containing sporadic "@" characters.
If such a pattern is encountered, the command parser of CMake slows down significantly. In our case from taking ...Hi everyone.
We've discovered an issue with CMake's handling of large string constants containing sporadic "@" characters.
If such a pattern is encountered, the command parser of CMake slows down significantly. In our case from taking half a second to taking a minute to handle the file.
This bug affects all CMake versions tested by us -- starting with 2.8.7 all the way up 3.8.0-rc1 -- both on Windows as well as Linux.
In our case, this makes a build that usually runs in 9 Minutes take 32 minutes instead.
All you need to do, to replicate this bug is to create a "CMakeLists.txt" containing the following pattern:
`project(hello)
set(
STR
"<LONG-STRING>"
)
`
The long string is a list of Unix paths -- i.e. a mixture of letters and some punctuation separated by semicolons. To exbibit the bug, a few (but not all!) of the folders must contain an "@" character.
Attached, to this bug report, you can find 3 test files with a size of 125kB in size that can be run with `cmake -H. -Bbuild`.
The three files contain the same paths with the following "minor" differences:
* One replaces all "@" characters with "_" characters. This file is handled by cmake in **0.5 seconds**.
* One replace all "_" characters with "@". This file is handled by cmake in **0.75 seconds**.
* One uses a mixture of a few "@" and "_" otherwise. In this case cmake suddenly **needs 56 seconds** to finish.
We've timed this behaviour with various string lengths as follows, to show the way in which CMake runtime scales with string length.
`==== Testing 'No @ Chars' ====
10% (12729 chars) = 0.580 secs
20% (25458 chars) = 0.583 secs
30% (38187 chars) = 0.654 secs
40% (50916 chars) = 0.572 secs
50% (63645 chars) = 0.599 secs
60% (76374 chars) = 0.595 secs
70% (89103 chars) = 0.583 secs
80% (101832 chars) = 0.569 secs
90% (114561 chars) = 0.566 secs
100% (127290 chars) = 0.576 secs
==== Testing 'No _ Chars' ====
10% (12729 chars) = 0.573 secs
20% (25458 chars) = 0.578 secs
30% (38187 chars) = 0.591 secs
40% (50916 chars) = 0.573 secs
50% (63645 chars) = 0.600 secs
60% (76374 chars) = 0.621 secs
70% (89103 chars) = 0.691 secs
80% (101832 chars) = 0.705 secs
90% (114561 chars) = 0.717 secs
100% (127290 chars) = 0.737 secs
==== Testing 'Both @ and _' ====
10% (12729 chars) = 0.814 secs
20% (25458 chars) = 2.121 secs
30% (38187 chars) = 4.644 secs
40% (50916 chars) = 8.384 secs
50% (63645 chars) = 13.359 secs
60% (76374 chars) = 19.609 secs
70% (89103 chars) = 27.074 secs
80% (101832 chars) = 35.744 secs
90% (114561 chars) = 45.679 secs
100% (127290 chars) = 56.907 secs`
We've compiled cmake 3.8.0 with profiling data and received the following gprof analysis, showing which call is slowed down:
` % cumulative self self total
time seconds seconds calls s/call s/call name
83.58 92.99 92.99 303315 0.00 0.00 yy_get_previous_state(void*)
16.29 111.11 18.12 309471 0.00 0.00 yy_get_next_buffer(void*)
0.01 111.15 0.01 81098 0.00 0.00 cmake::GetVariableWatch()
`
The call sequence for that time-consuming method is:
`% time self children called name
0.00 111.11 39804/39804 cmCommandArgument_yyparse(void*) [7]
99.9 0.00 111.11 39804 cmCommandArgument_yylex(cmCommandArgumentParserHelper::ParserType*, void*) [9]
92.99 0.00 303315/303315 yy_get_previous_state(void*) [10]
18.12 0.00 309471/309471 yy_get_next_buffer(void*) [16]
0.00 0.00 14352/18451 cmCommandArgumentParserHelper::AllocateParserType(cmCommandArgumentParserHelper::ParserType*, char const*, int) [4878]
0.00 0.00 6156/6156 cmCommandArgument_yyensure_buffer_stack(void*) [5169]
0.00 0.00 6156/6156 cmCommandArgument_yy_create_buffer(_IO_FILE*, int, void*) [5165]
0.00 0.00 6156/18468 cmCommandArgument_yy_load_buffer_state(void*) [4877]
0.00 0.00 4099/4099 cmCommandArgumentParserHelper::HandleEscapeSymbol(cmCommandArgumentParserHelper::ParserType*, char) [5275]`
This shows, that most of the time is spent in the command argument parser.
To replicate this issue, you can find a TGZ file attached to this bug report that contains the requisite "CMakeLists.txt" files that exhibit that issue.
* The folder "adds" contains the file that contains many "@" characters.
* The folder "underscores" contains the file that contains no "@" characters.
* The folder "adds+underscores" contains exactly 5 "@" characters and exhibits the bug.
[long-string-bug.tgz](/uploads/72f5fa39723ee5dfbfead09ca72026a8/long-string-bug.tgz)https://gitlab.kitware.com/cmake/cmake/-/issues/16675ninja: absolute path to source breaks rebuild with generated header2018-10-31T07:29:33-04:00Martin Giesekingninja: absolute path to source breaks rebuild with generated headerI stumbled over an issue that seems to be related to https://public.kitware.com/Bug/view.php?id=14167. I use cmake 3.7.2 and ninja 1.7.2 together with gcc on Windows and Linux.
The following `CMakeList.txt` requires ninja to be called...I stumbled over an issue that seems to be related to https://public.kitware.com/Bug/view.php?id=14167. I use cmake 3.7.2 and ninja 1.7.2 together with gcc on Windows and Linux.
The following `CMakeList.txt` requires ninja to be called twice in order to rebuild the executable after modifications of `header.txt`. The first call of ninja only regenerates `header.h` from `header.txt` but doesn't rebuild the executable. Only if I call ninja a second time, it recognizes the modification and triggers the rebuild.
When using make instead of ninja, everything works correctly. This seems to be a bug in cmake 3.7.2 since ninja build files generated with cmake 3.6.2 work correctly too.
```cmake
cmake_minimum_required(VERSION 3.5)
project(testproject)
add_executable(testproject
header.h
main.c
)
add_custom_command(
OUTPUT header.h
DEPENDS header.txt
COMMAND ${CMAKE_COMMAND} -E copy header.txt header.h
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)
```
[testproject.zip](/uploads/dace77be5ba55e5f744c1808e38eb0d0/testproject.zip)Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16674set COMPILE_PDB_NAME to OBJECT library cause internal error2017-05-04T16:23:48-04:00comicfansset COMPILE_PDB_NAME to OBJECT library cause internal errorthis happened on 3.8.0-rc1 and latest (4e8742d78f9176a3476ec442d7353fc4b3a7a58a) version
call stack shows as
```
cmake.exe!cmGeneratorTarget::GetOutputInfo(const std::basic_string<char,std::char_traits<char>,std::allocator<c...this happened on 3.8.0-rc1 and latest (4e8742d78f9176a3476ec442d7353fc4b3a7a58a) version
call stack shows as
```
cmake.exe!cmGeneratorTarget::GetOutputInfo(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & config) Line 4373 C++
cmake.exe!cmGeneratorTarget::GetPDBDirectory(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & config) Line 5303 C++
cmake.exe!cmGeneratorTarget::GetCompilePDBPath(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & config) Line 1161 C++
cmake.exe!cmVisualStudio10TargetGenerator::WriteClOptions(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & configName, const std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > & includes) Line 2337 C++
cmake.exe!cmVisualStudio10TargetGenerator::WriteItemDefinitionGroups() Line 3145 C++
cmake.exe!cmVisualStudio10TargetGenerator::Generate() Line 507 C++
cmake.exe!cmLocalVisualStudio10Generator::Generate() Line 77 C++
cmake.exe!cmGlobalGenerator::Generate() Line 1327 C++
cmake.exe!cmGlobalVisualStudio7Generator::Generate() Line 292 C++
cmake.exe!cmGlobalVisualStudio10Generator::Generate() Line 384 C++
cmake.exe!cmake::Generate() Line 1623 C++
```
in cmGeneratorTarget::GetOutputInfo comments shows:
```C++
// Only libraries and executables have well-defined output files.
if (!this->HaveWellDefinedOutputFiles()) {
std::string msg = "cmGeneratorTarget::GetOutputInfo called for ";
msg += this->GetName();
msg += " which has type ";
msg += cmState::GetTargetTypeName(this->GetType());
this->LocalGenerator->IssueMessage(cmake::INTERNAL_ERROR, msg);
......
```
simple test project to trigger this:
```cmake
project (test)
cmake_minimum_required(VERSION 3.6)
add_library(a OBJECT a.cpp)
set_target_properties(a
PROPERTIES
COMPILE_PDB_NAME "cs"
)
```Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16673FindCURL doesn't report an error for non-existing file or mismatched version2017-05-04T16:23:48-04:00Yusuf GorenFindCURL doesn't report an error for non-existing file or mismatched versionI'm having the following problems with CMake 3.7.2 (build from [this](https://cmake.org/files/v3.7/cmake-3.7.2.tar.gz) source) under Ubuntu 16.04, all seemingly due to FindCURL.
1) If I pass `-DCURL_LIBRARY=/file/that/does/not/exist.s...I'm having the following problems with CMake 3.7.2 (build from [this](https://cmake.org/files/v3.7/cmake-3.7.2.tar.gz) source) under Ubuntu 16.04, all seemingly due to FindCURL.
1) If I pass `-DCURL_LIBRARY=/file/that/does/not/exist.so -DCURL_INCLUDE_DIR=/folder/that/does/not/exists` to `cmake` where my project has a `find_package(CURL 7.43.0 REQUIRED)`, nothing breaks until I make a target with `make myTarget` (of course, linker can't find the library or required headers are not included). Ideally, I should have at least a warning saying the file doesn't exist. Instead I get
```
Found CURL: /file/that/does/not/exist.so (Required is at least version "7.43.0")
```
2) Assuming that the library and include directory supplied exists (as a file and directory) but not `libcurl` in any manner, no error is produced again in the same project above. I practically get the same message as above.
3) Assuming that the library and include directory supplied exists and actually `libcurl` but smaller version, only a warning is issued with `REQUIRED` option while it should give an error with `REQUIRED` and a warning without it.
I have confirmed the same bug in 3.7.1 build from source on MacOS with the same identical project.
Thanks a lot!https://gitlab.kitware.com/cmake/cmake/-/issues/16672Tar creation path issues2019-05-21T20:30:50-04:00TimTar creation path issuesI have a directory that is generated at build time: `$CMAKE_BINARY_DIRECTORY/Pack`. It has a load of stuff in it that I'd like to zip: `Pack/a.txt`, `Pack/b.txt` and so on.
The problem is, there is *no* way to build a zip from those tha...I have a directory that is generated at build time: `$CMAKE_BINARY_DIRECTORY/Pack`. It has a load of stuff in it that I'd like to zip: `Pack/a.txt`, `Pack/b.txt` and so on.
The problem is, there is *no* way to build a zip from those that doesn't have a 'Pack' directory in it. I tried the following.
add_custom_target(zip
COMMAND ${CMAKE_COMMAND} -E tar "cfv" "${CMAKE_BINARY_DIR}/out.zip" --format=zip -- "${CMAKE_BINARY_DIR}/Pack/"
VERBATIM
)
That unfortunately puts everything in Pack. Then I looked in [the code](https://github.com/Kitware/CMake/blob/3c0de6db2d9e0580f23cc95c4a1e00a8f66108c9/Source/cmSystemTools.cxx#L1399-L1409), and saw that the final zip path depends on the working directory. So I tried this.
add_custom_target(zip
COMMAND ${CMAKE_COMMAND} -E tar "cfv" "${CMAKE_BINARY_DIR}/out.zip" --format=zip -- "${CMAKE_BINARY_DIR}/Pack/"
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}/Pack/"
VERBATIM
)
But that doesn't seem to add anything at all! I tried this:
add_custom_target(zip
COMMAND ${CMAKE_COMMAND} -E tar "cfv" "${CMAKE_BINARY_DIR}/out.zip" --format=zip -- "."
WORKING_DIRECTORY "${CMAKE_BINARY_DIR}/Pack/"
VERBATIM
)
That adds all the files, but it puts them as `./a.txt` and so on in the zip. 7-zip sort of understands this, but Windows just shows it as an empty zip. It's wrong in any case.https://gitlab.kitware.com/cmake/cmake/-/issues/16671Codelite projects can't be debugged/launched from Codelite2017-10-13T13:17:55-04:00Timo WiesemannCodelite projects can't be debugged/launched from CodeliteWhen generating a "Codelite - Unix Makefiles" project, I can build everything.
But I cannot launch/debug a project from within Codelite.
It can't find the executable.
In each sub-project's settings the Output File is set to **./$(Proje...When generating a "Codelite - Unix Makefiles" project, I can build everything.
But I cannot launch/debug a project from within Codelite.
It can't find the executable.
In each sub-project's settings the Output File is set to **./$(ProjectName)**, which seems to be **${CMAKE_BINARY_DIR}/${PROJECT_NAME}** (see image).
In my project the binaries are *not* build in the root of **${CMAKE_BINARY_DIR}**.
Stepping through the cmake source I found that in *cmExtraCodeLiteGenerator.cxx* only **EXECUTABLE_OUTPUT_PATH** is queried for the binary output path,
which was always empty for the projects I tried - so it defaulted.
In my project I set them via **CMAKE_RUNTIME_OUTPUT_DIRECTORY**. If I change the code to query that variable first, the output filepath is set correctly.
That would help in my situation, where my binaries are named exactly like the project names.
It won't suffice for i.e the cmake source, where the project is named "CMake" but the executable is named "cmake".
OS: Lubuntu 16.04 LTS CMake version: 3.7.2, clang 3.8.0
![cmake-3.7.2_codelite_generator](/uploads/f3ecb55115e6308c256a94356b590bae/cmake-3.7.2_codelite_generator.png)https://gitlab.kitware.com/cmake/cmake/-/issues/16670Syntax error in FindBoost.cmake with Windows paths with backslashes2022-04-01T13:05:06-04:00Mirco CaramoriSyntax error in FindBoost.cmake with Windows paths with backslashes```
CMake Error at C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903 (list):
Syntax error in cmake code at
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903
when parsing string
C:\Dev\mongodb\src\boos...```
CMake Error at C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903 (list):
Syntax error in cmake code at
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:903
when parsing string
C:\Dev\mongodb\src\boost/lib${_arch_suffix}-msvc-15.0
Invalid character escape '\D'.
Call Stack (most recent call first):
C:/Dev/cmake/share/cmake-3.8/Modules/FindBoost.cmake:1379 (_Boost_UPDATE_WINDOWS_LIBRARY_SEARCH_DIRS_WITH_PREBUILT_PATHS)
src/bsoncxx/CMakeLists.txt:100 (find_package)
```