CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2020-11-14T03:48:56-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/20012Add a way to customize Visual Studio sln name2020-11-14T03:48:56-05:00Francesco PrettoAdd a way to customize Visual Studio sln nameI noticed that recent versions of CMake are [now](https://cmake.org/cmake/help/v3.15/command/project.html) requiring a "literal, direct" call to `project()` in the top-level CMakeLists.txt, issuing a warning if the call is not detected. ...I noticed that recent versions of CMake are [now](https://cmake.org/cmake/help/v3.15/command/project.html) requiring a "literal, direct" call to `project()` in the top-level CMakeLists.txt, issuing a warning if the call is not detected. The intent seems to avoid the `project()` call to be issued only inside an `include` directive, which seems a very reasonable requirement. The problem is that how it is now the check is very rough, also preventing any useful wrapping of `project()` calls inside a macro or a function. I provide an example of a `my_project()` function that wraps the call to `project()` adding useful suffixes to project name:
```
macro(my_project projectName)
if (MSVC)
# On Visual studio add informative suffix to project name
set(PROJECT_SUFFIX "-${ARCH}")
if (NOT "${CMAKE_BUILD_TYPE}" STREQUAL "")
set(PROJECT_SUFFIX "${PROJECT_SUFFIX}-${CMAKE_BUILD_TYPE}")
endif()
endif()
project(${projectName}${PROJECT_SUFFIX})
endmacro()
```
In the top-level CMakeLists, I call `my_project(Test)`, which want to be an indirect, but intended, call to `project()`. In Windows this allow the Visual Studio solution to have an useful name like `Test-${ARCH}-${CMAKE_BUILD_TYPE}.sln`. After the upgrade of CMake I now have this big warning that makes me uncomfortable. My specific issue has some obvious workarounds that are less elegant, but it would be probably solved better if there would exist a supported way to customize the VS solution name without changing the project name, something that doesn't seems to [exist](https://stackoverflow.com/a/46932536/213871).
Alternatively, it seems to me that requirement of having literal call to `project()` in the top-level CMakeLists is too strict and I'm sure there are other legit reasons to wrap it in macros or functions as I'm doing. In fact, I see that you added these `CMAKE_PROJECT_INCLUDE_BEFORE` and `CMAKE_PROJECT_INCLUDE` variables, but they seems just workarounds you added because of too strict check in your interpreter: you could have performed a narrowed check of just the unsafe situation, which I think it was having an unintended first call to `project()` issued in included files. Usually a well designed language interpreter has all the context information needed to detect such conditions. I don't understand why you chose to go this way adding before/after variables for external scripts (which are of course less comfortable to use than just wrapping `project()` in a macro/function) but it seems to me like a code smell.
I attached an example CMake project with usage of the above `my_project()` macro that issued no warning before 3.15.
[CMakeProjectCommandWrap.7z](/uploads/1cf34b53be16aa12534cc4eb9e08a473/CMakeProjectCommandWrap.7z)https://gitlab.kitware.com/cmake/cmake/-/issues/20006LINKER_LANGUAGE default for one-language executables linking mixed libraries2019-11-25T09:21:02-05:00Brad KingLINKER_LANGUAGE default for one-language executables linking mixed librariesConsider this example:
```cmake
add_library(SomeLibUsingCXX STATIC lib.cxx)
add_executable(MyFortranProgram main.F)
target_link_libraries(MyFortranProgram PRIVATE SomeLibUsingCXX)
set_property(TARGET MyFortranProgram PROPERTY LINKER_L...Consider this example:
```cmake
add_library(SomeLibUsingCXX STATIC lib.cxx)
add_executable(MyFortranProgram main.F)
target_link_libraries(MyFortranProgram PRIVATE SomeLibUsingCXX)
set_property(TARGET MyFortranProgram PROPERTY LINKER_LANGUAGE Fortran)
```
The last line is currently required to tell CMake that the Fortran compiler must be used to drive linking since the program entry point is in Fortran. This is mentioned in the [LINKER_LANGUAGE](https://cmake.org/cmake/help/v3.16/prop_tgt/LINKER_LANGUAGE.html) target property documentation.
When the last line is not present, CMake recognizes that both Fortran and C++ object files are included in the link (the latter through the library) and prioritizes selection of the C++ compiler over the Fortran compiler to drive linking. For a shared library that normally doesn't matter, but for an executable that selection may not match the language of the object file that contains the program entry point (`main`).
In the case that the actual sources listed in an executable target are all only one language, it is a reasonably good guess that one of those sources has the program entry point and so their language should be the default used to drive linking.https://gitlab.kitware.com/cmake/cmake/-/issues/20001CTest Coverage failing when building with Ninja in a subdirectory2023-10-22T16:14:51-04:00Kai PastorCTest Coverage failing when building with Ninja in a subdirectoryI just stumbled over a working "CTest -T coverage" setup (with Ninja and gcov) failing after a quite innocent change:
- Before the change, the build dir was a sibling directory of the source directory. The coverage step worked as expecte...I just stumbled over a working "CTest -T coverage" setup (with Ninja and gcov) failing after a quite innocent change:
- Before the change, the build dir was a sibling directory of the source directory. The coverage step worked as expected.
- After the change, the build dir was a (deep) subdirectory of the source directory. The coverage step fails. With a minimal test project, it reports "Cannot find any coverage files. Ignoring Coverage request."
In a verbose build, I noticed that the changed build dir has a side effect on Ninja builds but not Makefile builds:
- When the build dir is a sibling directory, gcc is called with the absolute path of the source file.
- When the build dir is a subdirectory, gcc is called with the relative path of the source file.
This side effect is no issue for compilation (cmake --build .) or running the test stage (ctest -T Test --no-compress-output). But I suspect this the reason for the failing coverage step, given that in my original setup, a subsequent CI coverage task on Azure pipelines fails as well, reporting incorrect absolute paths for expected source files.)
The attached ZIP file contains a minimal reproducing example. For a build in a subdir and in a sibling dir, the setup is the same:
~~~
cmake -G Ninja /ABSOULTE/PATH/TO/SOURCE
VERBOSE=1 cmake --build .
ctest -T Test --no-compress-output
ctest -T Coverage
~~~
[ninja-coverage.zip](/uploads/8182ca9882d2ba2087b1d5640d6683fc/ninja-coverage.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/19999UseJava: Add test cases for javadoc2019-11-20T10:44:42-05:00Brad KingUseJava: Add test cases for javadocThe UseJava module's `create_javadoc` function is not tested in `Tests/`.The UseJava module's `create_javadoc` function is not tested in `Tests/`.https://gitlab.kitware.com/cmake/cmake/-/issues/19997Text or json file to control unity batch files.2020-05-06T11:37:22-04:00Paul BakerText or json file to control unity batch files.# Proposal
Add a property to designate a text or json file that can describe how source files are arranged into the unity batch files.
The ability to create unity batch files that are more balanced for parallel compilation would make t...# Proposal
Add a property to designate a text or json file that can describe how source files are arranged into the unity batch files.
The ability to create unity batch files that are more balanced for parallel compilation would make the built in CMake Unity build feature much more useful. Plus it would help avoid issues with files that cannot be in the same batch files.
Paul Bakerhttps://gitlab.kitware.com/cmake/cmake/-/issues/19995CMAKE_INSTALL_PREFIX: relative to absolute path strange behavior2019-11-20T08:57:03-05:00albertoinvernizziCMAKE_INSTALL_PREFIX: relative to absolute path strange behaviorI'm experiencing a behavior on how relative paths are expanded to absolute, that looks strange to me (just for reference I'm using 3.15.5).
### Reference `CMakeLists.txt`
Let's take this reference example
```cmake
project(relative_vs...I'm experiencing a behavior on how relative paths are expanded to absolute, that looks strange to me (just for reference I'm using 3.15.5).
### Reference `CMakeLists.txt`
Let's take this reference example
```cmake
project(relative_vs_absolute)
cmake_minimum_required(VERSION 3.15)
message(STATUS ${CMAKE_INSTALL_PREFIX})
message(STATUS ${other_var})
```
### `cmake`
First attempt
```bash
$ cmake -DCMAKE_INSTALL_PREFIX="here" -Dother_var="there" ..
... (not relevant output) ...
-- /Users/ialberto/workspace/tmp/cmake_expand_install_prefix/build/here
-- there
$ egrep "(CMAKE_INSTALL_PREFIX|other_var)" CMakeCache.txt
CMAKE_INSTALL_PREFIX:PATH=/Users/ialberto/workspace/tmp/cmake_expand_install_prefix/build/here
other_var:UNINITIALIZED=there
```
`CMAKE_INSTALL_PREFIX` is automatically translated to absolute path, while `other_var` not. So, I thought it was a matter of variable type. But,
```bash
$ cmake -DCMAKE_INSTALL_PREFIX:PATH="here" -Dother_var:PATH="there" ..
-- here
-- there
$ egrep "(CMAKE_INSTALL_PREFIX|other_var)" CMakeCache.txt
CMAKE_INSTALL_PREFIX:PATH=here
other_var:PATH=there
```
Specifying both as `PATH` variables, no one gets translated to absolute path.
I may agree with you that automatically translating a PATH that is relative to its absolute path would be a too strong assumption and constraint.
But, from [set() documentation](https://cmake.org/cmake/help/v3.15/command/set.html?highlight=set#set-cache-entry)
> Furthermore, if the <type> is PATH or FILEPATH and the <value> provided on the command line is a relative path, then the set command will treat the path as relative to the current working directory and convert it to an absolute path.
So, IMHO I would expect that specifying `PATH` as variable type, both of them would get translated to absolute path.
### `ccmake`
Then, with this in mind, I started experimenting with `ccmake`.
At first sight, it behaves exactly as `cmake`. (I changed from `message(STATUS)` to `message(WARNING)` for convenience)
```bash
$ ccmake -DCMAKE_INSTALL_PREFIX="here" -Dother_var="there" ..
CMake Warning at CMakeLists.txt:4 (message):
/Users/ialberto/workspace/tmp/cmake_expand_install_prefix/build/here
CMake Warning at CMakeLists.txt:5 (message):
there
$ egrep "(CMAKE_INSTALL_PREFIX|other_var)" CMakeCache.txt
CMAKE_INSTALL_PREFIX:PATH=/Users/ialberto/workspace/tmp/cmake_expand_install_prefix/build/here
other_var:UNINITIALIZED=there
```
```bash
$ ccmake -DCMAKE_INSTALL_PREFIX:PATH="here" -Dother_var:PATH="there" ..
CMake Warning at CMakeLists.txt:4 (message):
here
CMake Warning at CMakeLists.txt:5 (message):
there
$ egrep "(CMAKE_INSTALL_PREFIX|other_var)" CMakeCache.txt
CMAKE_INSTALL_PREFIX:PATH=here
other_var:PATH=there
```
But, if I set one of them from the user-interface, the variables are set to the exact value I set into. I can explain this to me with the fact that it just do a string-replacement of values, without any additional logic like when specified from the command line.
### Conclusion
Everything started because I'm using a project that assumes that `CMAKE_INSTALL_PREFIX` is an absolute path, but I used to set it through `ccmake` user interface, and I was installing it (for testing reason) in a directory nested in the build-dir, specifying a relative path (e.g. `install_here`).
- IMHO the `cmake` behavior is not coherent with the documentation (or I'm missing something from the documentation);
- I don't know if I can expect that setting variables from `ccmake` user-interface would have the same behavior as setting them from the command line.https://gitlab.kitware.com/cmake/cmake/-/issues/19994Help: Clarify when CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is set2019-11-19T15:31:25-05:00Benjamin GiesingerHelp: Clarify when CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is setHi,
I just wanted to check my install prefix and, if it is default, reroute it. The documentation says:
```cmake
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX "/my/default" CACHE PATH "..." FORCE)
endif()
`...Hi,
I just wanted to check my install prefix and, if it is default, reroute it. The documentation says:
```cmake
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
set(CMAKE_INSTALL_PREFIX "/my/default" CACHE PATH "..." FORCE)
endif()
```
However there are 2 things:
1. Shouldn't it be ```if(${CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT})``` ?
2. Either way does not return anything on the variable
I also check the "Mastering CMake" Book which doesn't even list this variable. Any way I can work around this issue that doesn't involve string compare?
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/19990Xcode: Objective C linking adds -fobjc-link-runtime2019-11-22T09:23:11-05:00Tobias HietaXcode: Objective C linking adds -fobjc-link-runtimeHello,
With 3.16 we use the new support for Objective-C/C++ and we noticed that the Xcode generator failed to configure with the following error:
```
-- Check for working OBJC compiler: /Applications/Xcode.app/Contents/Developer/Toolch...Hello,
With 3.16 we use the new support for Objective-C/C++ and we noticed that the Xcode generator failed to configure with the following error:
```
-- Check for working OBJC compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - broken
CMake Error at /Users/tobias/.conan_plex/.conan/data/cmake/3.16.0-01169386-0/plex/stable/package/b9cf9bf841aca97ce334c83f6fb7c40f3bd8db7d/share/cmake-3.16/Modules/CMakeTestOBJCCompiler.cmake:57 (message):
The Objective-C compiler
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/xcodebuild -project CMAKE_TRY_COMPILE.xcodeproj build -target cmTC_08d46 -configuration Debug -hideShellScriptEnvironment && User defaults from command line:
HideShellScriptEnvironment = YES
Prepare build
note: Using legacy build system
=== BUILD TARGET cmTC_08d46 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug ===
Check dependencies
Write auxiliary files
/bin/mkdir -p /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64
write-file /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/cmTC_08d46.LinkFileList
CompileC CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/testOBJCCompiler.o testOBJCCompiler.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -target x86_64-apple-macos10.9 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-implicit-atomic-properties -Wno-objc-interface-ivars -Wno-arc-repeated-use-of-weak -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-float-conversion -Wno-non-literal-null-conversion -Wno-objc-literal-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -DCMAKE_INTDIR=\"Debug\" -DOBJC_OLD_DISPATCH_PROTOTYPES=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -Wno-infinite-recursion -Wno-comma -Wno-block-capture-autoreleasing -Wno-strict-prototypes -Wno-semicolon-before-method-body -I/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/Debug/include -I/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/DerivedSources-normal/x86_64 -I/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/DerivedSources/x86_64 -I/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/Debug -MMD -MT dependencies -MF /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/testOBJCCompiler.d --serialize-diagnostics /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/testOBJCCompiler.dia -c /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/testOBJCCompiler.m -o /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/testOBJCCompiler.o
Ld Debug/cmTC_08d46 normal x86_64
cd /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-macos10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -L/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/Debug -F/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/Debug -filelist /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/cmTC_08d46.LinkFileList -Xlinker -object_path_lto -Xlinker /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/cmTC_08d46_lto.o -Xlinker -no_deduplicate -fobjc-link-runtime -Wl,-no_weak_imports -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Xlinker -dependency_info -Xlinker /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_08d46.build/Objects-normal/x86_64/cmTC_08d46_dependency_info.dat -o /Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeTmp/Debug/cmTC_08d46
ld: weak import of symbol '_objc_autoreleasePoolPush' not supported because of option: -no_weak_imports for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **
The following build commands failed:
Ld Debug/cmTC_08d46 normal x86_64
(1 failure)
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
See also "/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeOutput.log".
See also "/Users/tobias/Code/objc-xcode/b/CMakeFiles/CMakeError.log".
```
This is obviously because we pass `-DCMAKE_EXE_LINKER_FLAGS="-Wl,-no_weak_imports"` - but using the correct deployment target should fix this: `-DCMAKE_OSX_DEPLOYMENT_TARGET=10.9` and it doesn't.
This doesn't happen with the Ninja generator.
I did a small test cmakefile:
```
cmake_minimum_required(VERSION 3.16 FATAL_ERROR)
project(test-objc C OBJC)
```
then invoke it with:
`cmake -GXcode -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 -DCMAKE_EXE_LINKER_FLAGS="-Wl,-no_weak_imports" ..`
and
`cmake -GNinja -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 -DCMAKE_EXE_LINKER_FLAGS="-Wl,-no_weak_imports" ..`
and only the Xcode one fails.https://gitlab.kitware.com/cmake/cmake/-/issues/19982CPack + NSIS + Components with '-' in the name2019-12-03T11:30:37-05:00Ravi RamaseshanCPack + NSIS + Components with '-' in the name[CMakeTest.zip](/uploads/6ef961b9fc424647c395313b9cf5cf6a/CMakeTest.zip)
cmake --version
cmake version 3.15.0
cpack --version
cpack version 3.15.0
This can easily be reproduced with the LLVM build system making it hard to package spe...[CMakeTest.zip](/uploads/6ef961b9fc424647c395313b9cf5cf6a/CMakeTest.zip)
cmake --version
cmake version 3.15.0
cpack --version
cpack version 3.15.0
This can easily be reproduced with the LLVM build system making it hard to package specific binaries for distribution.
```
cd CMakeTest
mkdir build
cd build
cmake -GNinja -DCPACK_COMPONENTS_ALL=make-1;make-2 ..\
ninja package
CPack: Create package using NSIS
CPack: Install projects
CPack: - Install project: myproject
CPack: - Install component: make-1
CPack: - Install component: make-2
CPack: Create package
CPack Error: Problem running NSIS command: ".../makensis.exe" ".../CMakeTest/build/_CPack_Packages/win64/NSIS/project.nsi"
Please check .../CMakeTest/build/_CPack_Packages/win64/NSIS/NSISOutput.log for errors
CPack Error: Problem compressing the directory
CPack Error: Error when generating package:
FAILED: CMakeFiles/package.util
cmd.exe /C "cd /D "...\CMakeTest\build" && "...\CMake\bin\cpack.exe" --config ./CPackConfig.cmake"
ninja: build stopped: subcommand failed.
cat ".../CMakeTest/build/_CPack_Packages/win64/NSIS/NSISOutput.log"
# Run command: ".../NSIS/makensis.exe" ".../CMakeTest/build/_CPack_Packages/win64/NSIS/project.nsi"
# Output:
Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
Processing script file: ".../CMakeTest/build/_CPack_Packages/win64/NSIS/project.nsi" (ACP)
Error: invalid characters in variable name "make-1_selected", use only characters [a-z][A-Z][0-9] and '_'
Error in script ".../CMakeTest/build/_CPack_Packages/win64/NSIS/project.nsi" on line 54 -- aborting creation process
```https://gitlab.kitware.com/cmake/cmake/-/issues/19976multiple pre-build command comments merge into single line of output2022-01-19T10:17:07-05:00Dmitry Krivosheinmultiple pre-build command comments merge into single line of outputAdding a pre-build custom command with `AUTOMOC` enabled prepends its `COMMENT` string before `AUTOMOC` message in output:
```
$ ../cmake-3.16.20191113-gfd8db8f-win64-x64/bin/cmake.exe --build . --config Release -- -v:m -nologo
executi...Adding a pre-build custom command with `AUTOMOC` enabled prepends its `COMMENT` string before `AUTOMOC` message in output:
```
$ ../cmake-3.16.20191113-gfd8db8f-win64-x64/bin/cmake.exe --build . --config Release -- -v:m -nologo
executing pre-build command Automatic MOC for target prebuild
pre-build executed
...
```
Generated vcxproj file contents:
```
<Message>executing pre-build command Automatic MOC for target prebuild</Message>
^ TAB here
```
Adding `'\n'` after COMMENT only adds another tab between strings.
Tested with Visual Studio 2017.
Minimal example:
[class.h](/uploads/adc2da0ad8eb142c810a538d2a9fab51/class.h)
[class.cpp](/uploads/6276bea207727f13cb59a871ab9328ea/class.cpp)
[main.cpp](/uploads/752e66a9f8dfcd537e67bf08fedce8d3/main.cpp)
[CMakeLists.txt](/uploads/f5395f1dad7cde83332cbb1a6d0e353a/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/19975include_external_msproject does not work correctly with Ninja generator2021-03-05T04:15:18-05:00zjturnerinclude_external_msproject does not work correctly with Ninja generatorWhen I use the Ninja generator and include_external_msproject, no rules are generated anywhere in the Ninja file to build the msproject. You can see this with a simple example which uses `include_external_msproject(foo path/to/foo.vcxpr...When I use the Ninja generator and include_external_msproject, no rules are generated anywhere in the Ninja file to build the msproject. You can see this with a simple example which uses `include_external_msproject(foo path/to/foo.vcxproj)` and then generating with Ninja and typing `ninja -v foo`. The output is simply: `ninja: no work to do.`
According to the documentation [here](https://cmake.org/cmake/help/v3.8/command/include_external_msproject.html?highlight=i), it only mentions that this function does nothing on UNIX platforms, which would suggest that Ninja on Windows should be supported.https://gitlab.kitware.com/cmake/cmake/-/issues/19974VS: Providing the `/AI` compiler option results in two `<AdditionalUsingDirec...2020-06-25T02:40:49-04:00Oleg GubanovVS: Providing the `/AI` compiler option results in two `<AdditionalUsingDirectories>` elementsI have a managed C++ target AAA that depends on a native C++ static library BBB and another managed C++ target CCC. In AAA, I must use CCC **as friend**:
#using "CCC.dll" as_friend
For this to work, I need to provide `CCC.dll`'s folde...I have a managed C++ target AAA that depends on a native C++ static library BBB and another managed C++ target CCC. In AAA, I must use CCC **as friend**:
#using "CCC.dll" as_friend
For this to work, I need to provide `CCC.dll`'s folder with `/AI` compiler option:
target_compile_options(AAA PRIVATE /AI"${CMAKE_BINARY_DIR}/bin")
In the generated project file `AAA.vcxproj`, I expect to see the `<AdditionalUsingDirectories>` XML element that contains the expanded value of `"${CMAKE_BINARY_DIR}/bin"`. And I do see it, but then in the same `<ClCompile>` XML element there is the second `<AdditionalUsingDirectories>` XML element that contains the library directory of `BBB`. This second `<AdditionalUsingDirectories>` overwrites the folder that I set with `/AI` compiler option. The `#using` statement results in compilation errors, and there seems to be no way to fix the problem from my `CMakeLists.txt`.
The expected behavior would be to generate one `<AdditionalUsingDirectories>` XML element that merges paths coming from my `/AI` option and paths coming from dependencies.https://gitlab.kitware.com/cmake/cmake/-/issues/19973CPack + productbuild + install_name_tool: no LC_RPATH load command with path2020-03-25T15:29:18-04:00RomanCPack + productbuild + install_name_tool: no LC_RPATH load command with pathWhen i try to package an app under macOS with productbuild I get the following error with CPack 3.15.4: "error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load co...When i try to package an app under macOS with productbuild I get the following error with CPack 3.15.4: "error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load command with path: /opt/Qt/5.11.3/clang_64/lib found in" "(for architecture x86_64), required for specified option "-delete_rpath /opt/Qt/5.11.3/clang_64/lib""
The path "/opt/Qt/5.11.3/clang_64/lib" exist
I already tried Xcode 10.3 and Xcode 11.2.1https://gitlab.kitware.com/cmake/cmake/-/issues/19969ExternalProject fails when using paths with backslashes on Windows2020-11-24T20:52:27-05:00Alexander SharovExternalProject fails when using paths with backslashes on WindowsConsider the following CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.8)
project(test LANGUAGES)
include(ExternalProject)
ExternalProject_Add(move_file
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}
CONFIGURE_COMMAND type nul >...Consider the following CMakeLists.txt:
```cmake
cmake_minimum_required(VERSION 3.8)
project(test LANGUAGES)
include(ExternalProject)
ExternalProject_Add(move_file
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}
CONFIGURE_COMMAND type nul > "<SOURCE_DIR>\\test.txt"
BUILD_COMMAND move "<SOURCE_DIR>\\test.txt" "<BINARY_DIR>"
INSTALL_COMMAND ""
LOG_BUILD 1
)
```
When building it on Windows with CMake v3.12.4, i get the following error:
```
CMake Error at D:/src/cmake-test/_b/move_file-prefix/src/move_file-stamp/move_file-build-Debug.cmake:16 (message):
Command failed: The system cannot find the file specified
'move' 'D:/src/cmake-test est.txt' 'D:/src/cmake-test/_b/move_file-prefix/src/move_file-build
```
It looks like `\\t` from `"<SOURCE_DIR>\\test.txt"` has turned into `\t`, which made the path invalid.
However, if we just remove `LOG_BUILD 1` argument, it builds without problems.https://gitlab.kitware.com/cmake/cmake/-/issues/19968FindProtobuf: Document PROTOBUF_GENERATE_CPP_APPEND_PATH2019-11-13T09:26:18-05:00Harry MallonFindProtobuf: Document PROTOBUF_GENERATE_CPP_APPEND_PATHI was working on a protobuf cmake project with nested proto files as below. The output .cc and .h files were being put into the build folder directly (the directory structure was lost) which was causing issues. It turns out cmake has a m...I was working on a protobuf cmake project with nested proto files as below. The output .cc and .h files were being put into the build folder directly (the directory structure was lost) which was causing issues. It turns out cmake has a magic variable in `generate_protobuf` called `PROTOBUF_GENERATE_CPP_APPEND_PATH` which, when set to `Off` makes this work as I expected.
```sh
proto
├── CMakeLists.txt
└── dir
├── dir
│ └── v1
│ ├── foo.proto
│ └── utils.proto
└── dir
├── dir
│ └── v1
│ └── bar.proto
└── dir
└── v1
└── baz.proto
```
and CMakeLists.txt using `protobuf_generate_cpp`.
It seems to have been there forever but is not documented well. I don't think I understand it well enough to be able to document it myself.https://gitlab.kitware.com/cmake/cmake/-/issues/19966CMake hangs on select() call when starting MSVC link.exe via Wine2020-02-13T04:57:48-05:00ArtalusCMake hangs on select() call when starting MSVC link.exe via WineSo we have a somewhat peculiar setup:
- Linux
- with LVM image file mounted
- `chroot` in system in this mount
- CMake in said chroot
- uses wrapper shell-scripts specified in Toolchain file
- to call VS 2013 toolchain utilities cl...So we have a somewhat peculiar setup:
- Linux
- with LVM image file mounted
- `chroot` in system in this mount
- CMake in said chroot
- uses wrapper shell-scripts specified in Toolchain file
- to call VS 2013 toolchain utilities cl.exe, link.exe, etc.
- via Wine emulator.
And at some point something in this chain fails.
When building our VS2013 project (couple dozens `.dll`s) some linker calls hang indefinitely *after* the linker itself finishes. So while there is a linked library file in my build directory, there is also a process in form of `cmake -E vs_link_dll --intdir=project/CMakeFiles/grabSimpleIP.dir --rc=/WineMSVC/bin/wx-rc --mt=/WineMSVC/bin/wx-mt --manifests -- /WineMSVC/bin/wx-link /nologo ...` waiting for something.
The issue is always caused by the same library, with other 30 being built just fine. However if I comment it out from my `CMakeLists.txt`, the problem reappears on some other library, which leads me to assumption that there is nothing wrong with the library itself (or there is something else fundamentally wrong).
Our `wx-link` wrapper:
```bash
source _msvc_wine_wrapper_common.sh # transforms /unix/paths to Z:\windows\paths
wine link.exe ${MSVC_TO_ARGS}
RC=$?
if [[ ! $RC -eq 0 ]]
then
printf "====COMMAND: wine link.exe ${MSVC_TO_ARGS}\n"
printf "====ORIG_ARGS-D: wx-link ${ORIG_ARGS}\n"
echo "Returned code: $RC"
exit $RC
fi
exit 0
```
If I run said `cmake -E vs_link_dll` under `strace`, it tells me that the process waits on `select(6, [5], NULL, NULL, NULL`.
I digged down to very `kwsysProcessWaitForPipe` in `CMake/Source/kwsys/ProcessUNIX.c`, and yes, there is
```c
while (((numReady = select(max + 1, &cp->PipeSet, 0, 0, timeout)) < 0) && ...
```
that causes CMake to hang.
The call stack in question:
```
kwsysProcessWaitForPipe @ Source/kwsys/ProcessUNIX.c
kwsysProcess_WaitForData @ Source/kwsys/ProcessUNIX.c
cmSystemTools::RunSingleCommand @ Source/cmSystemTools.cxx
RunCommand @ Source/cmcmd.cxx
cmVSLink::LinkNonIncremental @ Source/cmcmd.cxx
cmVSLink::Link @ Source/cmcmd.cxx
cmcmd::VisualStudioLink @ Source/cmcmd.cxx
```
In `RunSingleCommand` there is `cmsysProcess_WaitForData` being called that resolves to `kwsysProcess_WaitForData`, due to some preprocessing magic, apparently.
Looking at `RunSingleCommand` one can see that at the point of `WaitForData` the process itself has finished fine - which explains why there is a built library, so the problem happens somewhere in output processing. It happens even if the linker fails and returns non-zero exit code, and even if I make the wrapper completely silent by redirecting `wine link.exe ${MSVC_TO_ARGS} 1>/dev/null 2>/dev/null`.https://gitlab.kitware.com/cmake/cmake/-/issues/19963ARMClang: CMAKE_ASM_COMPILER_TARGET does not take effect when compiling Assem...2021-01-11T14:06:01-05:00Oscar HuangARMClang: CMAKE_ASM_COMPILER_TARGET does not take effect when compiling Assembly ARM codeSee issue https://gitlab.kitware.com/cmake/cmake/issues/19962 for the same configuration. When compiling Assembly code with the same CMakeLists.txt, armclang does not get --target=CMAKE_ASM_COMPILER_TARGET such that it complains --target...See issue https://gitlab.kitware.com/cmake/cmake/issues/19962 for the same configuration. When compiling Assembly code with the same CMakeLists.txt, armclang does not get --target=CMAKE_ASM_COMPILER_TARGET such that it complains --target is not defined and stop compiling. With C code, --target option is appened as expected.https://gitlab.kitware.com/cmake/cmake/-/issues/19960VS_DPI_AWARE not picked up by Ninja generator2019-11-11T16:32:14-05:00RadMapVS_DPI_AWARE not picked up by Ninja generatorVS_DPI_AWARE is a new flag since CMake 3.16. Buiding a Windows application with Visual Studio generator gives the expected result when this flag i set but when I use ninja it has no effect. The Ninja community suggests that this is a CMa...VS_DPI_AWARE is a new flag since CMake 3.16. Buiding a Windows application with Visual Studio generator gives the expected result when this flag i set but when I use ninja it has no effect. The Ninja community suggests that this is a CMake issue. Is this the case or should the flag be specifically handeled on the Ninja side?https://gitlab.kitware.com/cmake/cmake/-/issues/19959Formatting tool for CMake language2021-07-08T09:14:52-04:00jakubrakFormatting tool for CMake languageI am willing to implement the feature described below and curious about opinions.
The idea is to make a tool for formatting CMake files similar to [ClangFormat](https://clang.llvm.org/docs/ClangFormat.html). It would be a separate execu...I am willing to implement the feature described below and curious about opinions.
The idea is to make a tool for formatting CMake files similar to [ClangFormat](https://clang.llvm.org/docs/ClangFormat.html). It would be a separate executable (cmake-format ?) which would read configuration file (.cmake-format) and apply formatting defined in it. Configuration file would be placed in the same location as CMakeLists.txt. If not present, formatting as in parent CMakeLists.txt would be applied.
The idea of implementation is pretty simple. We need parser and generator. CMakeLists.txt file is parsed to AST (Abstract Syntax Tree) and then from it new formatted output is generated with applied rules from configuration file. The most difficult part is decoupling of CMake commands parsing and execution, which I moved to another issue #19958 , since it could be prerequisite for some other feature requests.https://gitlab.kitware.com/cmake/cmake/-/issues/19958Decouple command parsing from execution2019-11-17T09:25:34-05:00jakubrakDecouple command parsing from executionI am willing to do refactoring described below and curious about opinions.
Currently in CMake command parsing is tightly coupled with command execution. This makes impossible to reuse parsing code for e.g. syntax highlighting, code comp...I am willing to do refactoring described below and curious about opinions.
Currently in CMake command parsing is tightly coupled with command execution. This makes impossible to reuse parsing code for e.g. syntax highlighting, code completion in IDEs or code formatting.
The idea is to decouple model creation and parsing completely. Parsed data can be represented e.g. as AST ([Abstract Syntaxt Tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree)). Also it would be great if it would be linked into separate library and/or executable for client reuse.
My branch: [19958_Decouple_command_parsing_from_execution](https://gitlab.kitware.com/jakubrak/cmake/commits/19958_Decouple_command_parsing_from_execution)