CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-02-19T19:21:08-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/16834tar / zip creation is very inflexible2022-02-19T19:21:08-05:00Timtar / zip creation is very inflexibleSuppose during my build I gather a load of files in `${CMAKE_BINARY_DIR}/Pack`. I want to zip the *contents* of that folder. As of today there is actually no good way to do that. The only way to get `cmake -E tar cfv ...` to make a zip t...Suppose during my build I gather a load of files in `${CMAKE_BINARY_DIR}/Pack`. I want to zip the *contents* of that folder. As of today there is actually no good way to do that. The only way to get `cmake -E tar cfv ...` to make a zip that doesn't contain a directory called `Pack`, but actually contains the *contents* of that directory is to list the contents explicitly like this:
cd /path/to/Pack
cmake -E tar cfv OutputFile.zip --format=zip -- /path/to/Pack/file1.txt /path/to/Pack/file2.txt /path/to/Pack/file3.txt
The problem is you can't just glob those files, because at configure time they haven't been copied there yet. I tried all sorts of working-directory / relative path combinations but none of them work. Some produce bizarre results like having a directory called `..` in the zip.
My current "solution" is to list all those file manually. That obviously sucks because you have to remember to add them to the list.
Possibly related: #8769https://gitlab.kitware.com/cmake/cmake/-/issues/16830add_custom_command's IMPLICIT_DEPENDS feature doesn't work as expected2019-05-29T08:00:01-04:00Attila Krasznahorkayadd_custom_command's IMPLICIT_DEPENDS feature doesn't work as expectedHi,
I recently discovered a behaviour of the `add_custom_command` that I believe is bogus.
In our software we make use of the ROOT "framework". (http://root.cern.ch) One defining feature of ROOT is its ability to handle C++ objects in ...Hi,
I recently discovered a behaviour of the `add_custom_command` that I believe is bogus.
In our software we make use of the ROOT "framework". (http://root.cern.ch) One defining feature of ROOT is its ability to handle C++ objects in a generic way, using so-called dictionaries. (It's a long story...) In order to generate a dictionary for a user class, one has to use one of the ROOT executables that generates the source file(s) for the dictionary, which the user then has to compile into his/her source code in an appropriate manner.
As you can guess, we use `add_custom_command` to run these dictionary source file generation commands. Since the dictionary generator is a C++ interpreter itself, it's not completely trivial to set up the dependencies for the custom command. But luckily `IMPLICIT_DEPENDS` is exactly what we need for it. Since it allows us to only specify the headers holding the classes that we **actually** want to generate a dictionary for, and not have to care about which other headers these "important" headers pull in.
However, we had to discover that `IMPLICIT_DEPENDS` doesn't play nicely with our CI system. Attached is a very simple demonstration of this. [implicitDepends.tar.gz2](/uploads/1e0d7723dba8b8c9ee80d5db784c2f51/implicitDepends.tar.gz2)
It runs a custom command to generate a source file, from a header file called `header1.h`. This `header1.h` file includes another file called `header2.h`.
The compilation of this project works just fine out of the box. But try to do the following after building the "project":
- Remove the `header2.h` file;
- Comment out the include of `header2.h` in `header1.h`.
When I try an incremental build after these changes, I get the following:
```
make[2]: *** No rule to make target `/Users/krasznaa/Development/cmake/implicitDepends/header2.h', needed by `output.cxx'. Stop.
make[1]: *** [CMakeFiles/DummyLibrary.dir/all] Error 2
make: *** [all] Error 2
```
Even though a clean build of the modified source works just fine. Also, if I add one more header to the source, the incremental build still works correctly.
Unfortunately in the current setup Make is exposed to the dependency rules generated previously, before it would have a chance to update those dependency rules for the latest status of the source code. I have to admit I have absolutely no idea how all of this is implemented in CMake itself, so I'd leave it up to you guys to figure out how to best fix it. Unfortunately until it is fixed our CI system is not nearly as reliable as we'd like it to be. :frowning2:
Cheers,
Attilahttps://gitlab.kitware.com/cmake/cmake/-/issues/16669Having executables named "test" causes Ninja generator to generate ambiguous ...2017-10-13T13:17:55-04:00Kris MalfettoneHaving executables named "test" causes Ninja generator to generate ambiguous rules...I first posted this on the users mailing list but thought at this point it was definitely a bug and wanted to report it here. The basic gist is this:
> The code that produces the "# Target aliases." section of the build.ninja seems to ...I first posted this on the users mailing list but thought at this point it was definitely a bug and wanted to report it here. The basic gist is this:
> The code that produces the "# Target aliases." section of the build.ninja seems to try and avoid ambiguities between targets but fails to consider built in cmake targets such as "test,install,install/strip,etc...". This way when executables are named "test" (please note that their target names are both unique and not "test") they cause the ninja generator to create ambiguous targets.
There is a fair bit of description and small example CMakeLists.txt setup to reproduce the problem in this thread: http://public.kitware.com/pipermail/cmake/2017-February/065004.html
In particular steps to reproduce are here: http://public.kitware.com/pipermail/cmake/2017-February/065014.html
Top level CMakeLists.txt:
`
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_subdirectory("subdir")
add_subdirectory("subdir2")
`
Subdir with CMakeLists.txt:
`
add_executable( "Foo.test" foo_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
`
subdir2 with CMakeLists.txt:
`
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Bar.test" COMMAND test )
`
Contents of both source files (obviously in their respective subdirectories):
`
int main( int, char** )
{
return 0;
}
`
If you need any other information please feel to contact me.
Thanking you in advance,
Krishttps://gitlab.kitware.com/cmake/cmake/-/issues/16667Makefiles: changing per-source flags recompiles all sources in a target2017-10-13T13:17:55-04:00Gábor SzijártóMakefiles: changing per-source flags recompiles all sources in a targetI have the following problem. All the sources of a target is recompiled when I would except the recompilation only of the files whose properties were modified by the 'SET_SOURCE_FILES_PROPERTIES' command.
example code: (not full stand...I have the following problem. All the sources of a target is recompiled when I would except the recompilation only of the files whose properties were modified by the 'SET_SOURCE_FILES_PROPERTIES' command.
example code: (not full standalone cmake code)
```
OPTION( SPECIAL_SWITCH "Special switch used only in one source" OFF)
IF ( ${SPECIAL_SWITCH })
SET_SOURCE_FILES_PROPERTIES( "my_source.cpp" PROPERTIES COMPILE_DEFINITIONS "MY_DEFINE")
ENDIF()
SET(Sources ... lot of source, containing the my_source.cpp too)
ADD_LIBRARY( MyObject OBJECT ${Sources})
```
After enabling/disabling the 'SPECIAL_SWITCH' option all the sources are recompiled present in the 'Sources' variable. The 'MY_DEFINE' definition is added only for the file 'my_source.cpp' as expected (checked in verbose mode). I can't see the reason why CMAKE recompiles the other '.obj' files..
Regards,
Gáborhttps://gitlab.kitware.com/cmake/cmake/-/issues/16645file(STRINGS ...) command doesn't convert to binary when CWD is not a build d...2018-06-11T11:21:59-04:00Samuel Brynerfile(STRINGS ...) command doesn't convert to binary when CWD is not a build directory (e.g. when run as script)The `file(STRINGS ...)` command tries automatically convert Intel Hex and Motorola S-record files to binary.
This has two issues:
- It fails silently if anything goes wrong (such as a malformed file) in which case the file is read no...The `file(STRINGS ...)` command tries automatically convert Intel Hex and Motorola S-record files to binary.
This has two issues:
- It fails silently if anything goes wrong (such as a malformed file) in which case the file is read normally without converting it to binary. There is also no way to debug this behaviour directly (i.e. get some kind of error message on why it failed) apart from using strace to check if an `open()`-call to "FileCommandStringsBinaryFile" was issued.
- It writes the converted file to disk, which fails if the current working directory isn't a cmake build folder. This can happen for example when `file(STRING ...)` is executed as part of a cmake script. This is made worse by above issue, as no error is output and the conversion fails silently.
See also the TODO in https://gitlab.kitware.com/cmake/cmake/blob/72cfb3c3d2e8f6167cf08289691f7b0c61d0d331/Source/cmFileCommand.cxx#L544)
To reproduce this behaviour, execute the following in an empty directory:
```
# create files
$ echo ":10010000214601360121470136007EFE09D2190140\n:100110002146017E17C20001FF5F16002148011928" > test.ihx
$ echo 'file(STRINGS test.ihx contents)\nmessage("file contents: ${contents}")' > script.cmake
# execute script
$ cmake -P script.cmake
file contents: :10010000214601360121470136007EFE09D2190140;:100110002146017E17C20001FF5F16002148011928
# mimic directory structure of a build folder
$ mkdir CMakeFiles
# Now, file(STRINGS ...) behaves as expected:
$ cmake -P script.cmake
file contents: !F;6;!G;6;~; ;!F;~;_;!H
```
I expect the output of this script to be the same, no matter where I execute it.
This was tested on Fedora 24 with cmake 3.6.2 from the system repository and the latest cmake from git (v3.8.0-rc1-99-g8ff8766)
----
Some notes on the context where I discovered this:
I'm working on a firmware for a microcontroller and I need some some safe-guard against overwriting critical sections in flash (such as a bootloader or a configuration sector). As my compiler doesn't seem to be able to prevent this I wrote a small cmake script (for maximum platform independence) that processes the final output (an Intel Hex file) and checks it against a protected address range. Manually parsing an Intel Hex file takes a while though and this is where I discovered that cmake can do this natively.
I'd like this check to be run after every compilation and possibly also when compiling without cmake/make (some users are using CodeBlocks) so it would be nice if my script is location independent ;)
In conclusion: This bug doesn't really affect me as I have a working (albeit a bit slow) solution already. Also, can I even do math with binary data inside a cmake script (e.g. "address + offset < limit" checks)?https://gitlab.kitware.com/cmake/cmake/-/issues/16590CMake fails to determine dependencies of preprocessor wrapped Fortran use sta...2017-10-25T19:25:24-04:00carlorosatiCMake fails to determine dependencies of preprocessor wrapped Fortran use statementsAdding 5 lines to[test_preprocess.F90](/uploads/21265026d994d65d0fc3973fa96f037a/test_preprocess.F90)illustrates the behavior.
```
#if defined(NOTDEFINEDANYWHERE)
#define STILLNOTDEFINED
#endif
#ifndef STILLNOTDEFINED
USE PPAvail...Adding 5 lines to[test_preprocess.F90](/uploads/21265026d994d65d0fc3973fa96f037a/test_preprocess.F90)illustrates the behavior.
```
#if defined(NOTDEFINEDANYWHERE)
#define STILLNOTDEFINED
#endif
#ifndef STILLNOTDEFINED
USE PPAvailable
#endif
```https://gitlab.kitware.com/cmake/cmake/-/issues/16570CHECK_CXX_COMPILER_FLAG returns wrong results with std flag with VS20152017-10-13T13:17:55-04:00Dario MangoniCHECK_CXX_COMPILER_FLAG returns wrong results with std flag with VS2015With VS2015 Update 3
```cmake
CHECK_CXX_COMPILER_FLAG("-std=c++11" CHECK_CXX_FLAG)
CHECK_CXX_COMPILER_FLAG("-std=gnu++11" CHECK_GNUCXX_FLAG)
```
both the `CHECK_...` variables return `1` although the compiler does not support any of...With VS2015 Update 3
```cmake
CHECK_CXX_COMPILER_FLAG("-std=c++11" CHECK_CXX_FLAG)
CHECK_CXX_COMPILER_FLAG("-std=gnu++11" CHECK_GNUCXX_FLAG)
```
both the `CHECK_...` variables return `1` although the compiler does not support any of them.
(There is a -std:c++14 flag, but it's not the same!)
EDIT:
I realize that the MSVC compiler does NOT give any error. So actually the command respects its promises.https://gitlab.kitware.com/cmake/cmake/-/issues/16546VS: Cannot compile two `.asm` files with the same name2017-10-13T13:17:55-04:00Egor PuginVS: Cannot compile two `.asm` files with the same nameHi,
There's some mess with generated Object File property in VS solution for .asm files. The repro is in archive.
Unpack, then run:
```
mkdir win32 && cd win32 && cmake .. && cmake --build .
```
I see:
```
CustomBuild:
B...Hi,
There's some mess with generated Object File property in VS solution for .asm files. The repro is in archive.
Unpack, then run:
```
mkdir win32 && cd win32 && cmake .. && cmake --build .
```
I see:
```
CustomBuild:
Building Custom Rule H:/Temp/101/CMakeLists.txt
CMake does not need to re-run because H:\Temp\101\win32\CMakeFiles\generate.stamp is up-to-date.
_MASM:
Assembling H:\Temp\101\1.asm...
cmd.exe /C "C:\Users\egor\AppData\Local\Temp\tmp5dd0185685ca4204854801f7d64c5345.cmd"
ml.exe /c /nologo /Zi /Fo"x.dir\Debug\/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\1.asm
_MASM:
Assembling H:\Temp\101\b3e3654a.dir\1.asm...
cmd.exe /C "C:\Users\egor\AppData\Local\Temp\tmp9593c5d4a3f34d2baea0f10f674db120.cmd"
ml.exe /c /nologo /Zi /Fo"x.dir\Debug\/b3e3654a.dir/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\b3
e3654a.dir\1.asm
H:\Temp\101\b3e3654a.dir\1.asm(1): fatal error A1000: cannot open file : x.dir\Debug\/b3e365a. [H:\Temp\101\win32\x.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\masm.targets(50,5): error MSB3721: The command "ml.exe /c /nologo /Zi /Fo"
x.dir\Debug\/b3e3654a.dir/1.obj" /D"_M_X86" /D"CMAKE_INTDIR="Debug"" /W3 /errorReport:prompt /safeseh /TaH:\Temp\101\b3e3654a.dir\1.asm" exited wit
h code 1. [H:\Temp\101\win32\x.vcxproj]
Done Building Project "H:\Temp\101\win32\x.vcxproj" (default targets) -- FAILED.
```
`/Fo` option for the second file (under tricky dir) is completely broken! `/Fo"x.dir\Debug\/b3e3654a.dir/1.obj"`
```
H:\Temp\101\b3e3654a.dir\1.asm(1): fatal error A1000: cannot open file : x.dir\Debug\/b3e365a.
```
[asm_repro.zip](/uploads/5ea1b29b6e4912426e3370b1e4470dab/asm_repro.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/16527Incorrect cyclic CTest configuration doesn't emit error code to the system2017-10-13T13:17:55-04:00Ruslan Baratovx@ruslo.devIncorrect cyclic CTest configuration doesn't emit error code to the systemHere is simple example of cyclic dependency:
```cmake
cmake_minimum_required(VERSION 3.7.1)
project(foo)
enable_testing()
add_test(NAME Foo COMMAND "${CMAKE_COMMAND}" -E echo "Foo")
add_test(NAME Boo COMMAND "${CMAKE_COMMAND}" -E echo "...Here is simple example of cyclic dependency:
```cmake
cmake_minimum_required(VERSION 3.7.1)
project(foo)
enable_testing()
add_test(NAME Foo COMMAND "${CMAKE_COMMAND}" -E echo "Foo")
add_test(NAME Boo COMMAND "${CMAKE_COMMAND}" -E echo "Boo")
set_tests_properties(
Foo
PROPERTIES
FIXTURES_CLEANUP B
FIXTURES_REQUIRED A
)
set_tests_properties(
Boo
PROPERTIES
FIXTURES_CLEANUP A
FIXTURES_REQUIRED B
)
```
The problem is that error message is printed but exit code from CTest is still zero:
```bash
> ctest
Error: a cycle exists in the test dependency graph for the test "Foo".
Please fix the cycle and run ctest again.
No tests were found!!!
> echo $?
0
```https://gitlab.kitware.com/cmake/cmake/-/issues/16485Check path length in Windows to be shorter than MAX_PATH2017-10-13T13:17:55-04:00alihaCheck path length in Windows to be shorter than MAX_PATH> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(...> In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. [[msdn](https://msdn.microsoft.com/en-ca/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath)]
This can cause a problem in complex projects, as I recently experienced it (as a result of this problem, Visual Studio could not find a dependency simply because the path was more than 260 characters).
IMHO, in Windows, when a path longer than MAX_PATH is detected, CMake should at least log a warning if not an error.https://gitlab.kitware.com/cmake/cmake/-/issues/16481CMake add_custom_target adds nonexistent file to ide2017-10-13T13:17:55-04:00DrPepperJoCMake add_custom_target adds nonexistent file to ideCMake adds a nonexistent file named "${CMAKE_BINARY_DIR}/CMakeFiles/testtarget" to (VS2015) if the following (stripped-down) script is run.
> cmake_minimum_required( VERSION 3.7.0 )
> project( test_sample VERSION 0.1 LANGUAGES CXX...CMake adds a nonexistent file named "${CMAKE_BINARY_DIR}/CMakeFiles/testtarget" to (VS2015) if the following (stripped-down) script is run.
> cmake_minimum_required( VERSION 3.7.0 )
> project( test_sample VERSION 0.1 LANGUAGES CXX )
> add_custom_target( testtarget COMMAND dir )https://gitlab.kitware.com/cmake/cmake/-/issues/16480file(LOCK GUARD FILE): Crashes in script mode2023-02-27T10:51:11-05:00Egor Puginfile(LOCK GUARD FILE): Crashes in script modeAssertion failed at `cmFileLockPool.cxx:63`.
Repro:
1. Create `my.cmake`.
2. Write:
```
file(
LOCK a
GUARD FILE
RESULT_VARIABLE lock_result
)
```
3. Run `cmake -P my.cmake`.
cmake 3.7.1, any configuration
debug calls abor...Assertion failed at `cmFileLockPool.cxx:63`.
Repro:
1. Create `my.cmake`.
2. Write:
```
file(
LOCK a
GUARD FILE
RESULT_VARIABLE lock_result
)
```
3. Run `cmake -P my.cmake`.
cmake 3.7.1, any configuration
debug calls abort()
release is crashed because container is emptyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16451FindCURL does not search `C:\Program Files (x86)\CURL`2017-10-13T13:17:55-04:00EthanFindCURL does not search `C:\Program Files (x86)\CURL`I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails c...I have tried to install a couple of libraries that depend on libcurl. So I downloaded curl 7.51 and build and ran INSTALL.vcxproj and it installed fine.
However, when I run a cmake file that uses `find_package` to get CURL, it fails complaining it cannot find curl. cURL is installed in C:\Program Files (x86)\CURL for me. shouldn't cmake be looking for CURL in this standard path?
Am I doing something wrong?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/16434ExternalProject had redundant download and extract steps for multi configurat...2017-10-13T13:17:55-04:00Doug CrawfordExternalProject had redundant download and extract steps for multi configuration projectsIn a multi config build the time stamps for each step are independent and saved in the respective config folder under the stamp folder (Debug and Release). This causes the download extract, patch steps to be repeated for each configurat...In a multi config build the time stamps for each step are independent and saved in the respective config folder under the stamp folder (Debug and Release). This causes the download extract, patch steps to be repeated for each configuration. This is a problem for in source builds (BUILD_IN_SOURCE 1) since the whole source tree (and build artifacts) get replaced when the second config is built. In source builds are needed for classic visual studio projects (not cmake based).
Wouldn't it be better to have all the configurations (Debug and Release) share the download, extract, patch steps. Could this be solved by just moving the -mkdir, -download, -update, -patch timestamps to their parent directory so they are shared between all configs?https://gitlab.kitware.com/cmake/cmake/-/issues/16431cmake -P: no warnings/errors on unused command line arguments2022-12-07T09:08:55-05:00Ruslan Baratovx@ruslo.devcmake -P: no warnings/errors on unused command line arguments```
> cat script.cmake
message("Variable A: ${A}")
```
```
> cmake -DA=42 this-is-junk -P script.cmake this-is-junk
Variable A: 42
> echo $?
0
```
It would be nice to have at least warning in this case.```
> cat script.cmake
message("Variable A: ${A}")
```
```
> cmake -DA=42 this-is-junk -P script.cmake this-is-junk
Variable A: 42
> echo $?
0
```
It would be nice to have at least warning in this case.https://gitlab.kitware.com/cmake/cmake/-/issues/16395Escaping dollar sign with ninja generator.2023-06-30T11:35:15-04:00Ben WagnerEscaping dollar sign with ninja generator.When using the Ninja generator with '$' in various places on Linux (cmake version 3.7.20161031-g098a1) the following will setup will (silently) create an invalid ninja configuration which will not build, and once that is fixed will creat...When using the Ninja generator with '$' in various places on Linux (cmake version 3.7.20161031-g098a1) the following will setup will (silently) create an invalid ninja configuration which will not build, and once that is fixed will create one which silently does the unintended things.
```
cmake_minimum_required(VERSION 3.7)
add_executable(foo "more$.cpp")
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES "${CMAKE_CURRENT_LIST_DIR}/binof$")
set_target_properties(foo PROPERTIES COMPILE_DEFINITIONS "more$=good$")
set_target_properties(foo PROPERTIES COMPILE_FLAGS "-fmy$is=not$his")
set_target_properties(foo PROPERTIES LINK_FLAGS "rupies=$")
```
```
touch more\$.cpp
mkdir build
cd build
cmake -GNinja ..
ninja
```
* In some paths (INCLUDES) '$' seems to be escaped to '\$$' (ninja and shell), but sometimes not at all (DEP_FILE).
* In COMPILE_DEFINITIONS '$' is escaped to '\$$' in values, but is not escaped at all in names (ninja or shell).
* In COMPILE_FLAGS '$' is not escaped at all (ninja or shell)
* In LINK_FLAGS '$' is partially escaped to '$$' (ninja, but not shell)
The COMPILE_DEFINITIONS is interesting because the value goes through cmOutputConverter::EscapeForShell with sets Shell_Flag_Make and Shell_Flag_IsUnix, but the value does not.
Interestingly, this behavior appears to be consistent with the escaping in the Makefile generator. I can maybe understand that in certain places it might be undesirable to escape the shell (though I'm hard pressed to think of a good reason, I think CMake really doesn't want environment variables or backtick commands changing the build out from under it). However, the cases where values are not being escaped for the generator itself seem quite surprising. It means that a non-manually escaped '$' in COMPILE_FLAGS will silently cause a ninja rule to be written incorrectly.
The current behavior seems quite... inconsistent and not very well documented. Is there any hope for some consistency (an equivalent of VERBATIM for set?) or updated documentation pinning down what the rules are?https://gitlab.kitware.com/cmake/cmake/-/issues/16348CMake fails with space in Xcode app name2017-10-13T13:17:56-04:00EugeneCMake fails with space in Xcode app nameI have Xcode 7 and 8 installed side by side.
Xcode 7 is in `/Applications/Xcode.app`
Xcode 8 is in `/Applications/Xcode 8.app`
If I switch to xcode 8 with `xcode-select` I get this error when trying to generate xcode project with cmak...I have Xcode 7 and 8 installed side by side.
Xcode 7 is in `/Applications/Xcode.app`
Xcode 8 is in `/Applications/Xcode 8.app`
If I switch to xcode 8 with `xcode-select` I get this error when trying to generate xcode project with cmake:
```
- The C compiler identification is AppleClang 8.0.0.8000038
-- The CXX compiler identification is AppleClang 8.0.0.8000038
CMake Error in CMakeLists.txt:
No CMAKE_C_COMPILER could be found.
```https://gitlab.kitware.com/cmake/cmake/-/issues/16345Error reporting under Windows fails in command mode2021-03-11T08:59:24-05:00schaapError reporting under Windows fails in command modeIn a Windows command line, try:
```
cmake -E rename this_file_does_not_exist something_else
```
Your error response will be:
```
Error renaming from "this_file_does_not_exist" to "something_else": No error
```
Obviously the correct e...In a Windows command line, try:
```
cmake -E rename this_file_does_not_exist something_else
```
Your error response will be:
```
Error renaming from "this_file_does_not_exist" to "something_else": No error
```
Obviously the correct error would be that the source file does not exist.
This behaviour seems to stem from the use of errno under Windows in the function cmSystemTools::GetLastSystemError. While errno exists, it is apparently not reliable in returning the actual error. GetLastError() should probably be checked instead/as well.https://gitlab.kitware.com/cmake/cmake/-/issues/16342Ninja generator breaks when creating archives with GNU 'ar' in Windows2017-10-13T13:17:56-04:00Hai NguyenNinja generator breaks when creating archives with GNU 'ar' in WindowsThis is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'...This is related to these issues:
https://cmake.org/Bug/view.php?id=15278
and https://cmake.org/Bug/view.php?id=15439#c38728
The variation to the above mentioned issue is the usage of Clang and GNU 'ar' instead of of GCC and GNU 'ar'.
Based on what I can tell from the second issue, the fix was to detect if GCC was present and a forward slash was to be used instead. If the same thing can be applied to clang, it would be useful. Or maybe instead of it being compiler dependent, it should just see if it's GNU 'ar' since that's the common denominator.
I've tested this on cmd.exe and Git for Windows bash shell.