CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-04-07T08:39:27-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17558Fortran module dependencies across object libraries2022-04-07T08:39:27-04:00Melven Roehrig-ZoellnerFortran module dependencies across object librariesI'm using the inofficial ninja version that supports Fortran on a Windows machine with MinGW compilers.
In my CMake project I define multiple object libraries in different subdirectories.
By adjusting the include directories of the subd...I'm using the inofficial ninja version that supports Fortran on a Windows machine with MinGW compilers.
In my CMake project I define multiple object libraries in different subdirectories.
By adjusting the include directories of the subdirectories some of them can use Fortran modules from others, e.g.
```
src/
base_util/
base_math/ (can use modules from base_util)
abstract_core/ (can use modules from both base_util and base_math)
...
```
Now the first build works just fine. But when I modify e.g. a file in `base_util` ninja only recompiles other files in `base_util` and does ignore files that depend on the modified module in e.g. `abstract_core`.
This leads to corrupt executables in the worst case.
With other generators (Makefiles, MinGW Makefiles, MSVC) everything works fine.
Any idea on this?https://gitlab.kitware.com/cmake/cmake/-/issues/17557Stamp file generated during CMake configuration not detected by Ninja generator2017-12-12T10:44:06-05:00Attila KrasznahorkayStamp file generated during CMake configuration not detected by Ninja generatorDear All,
I'm trying to understand a pretty involved issue in our configuration. One which I was able to reproduce with a simplified project momentarily yesterday, but then couldn't reproduce it any more. But let me elaborate...
During...Dear All,
I'm trying to understand a pretty involved issue in our configuration. One which I was able to reproduce with a simplified project momentarily yesterday, but then couldn't reproduce it any more. But let me elaborate...
During the build of the [ATLAS](http://atlas.cern) offline software we build "converter libraries" out of source code that gets generated during the CMake configuration/build. ("Converters" for C++ classes that we wrote explicitly by hand.) As you can imagine, the generation of the source files is done through a combination of `add_custom_command` and `add_custom_target` calls.
Recently we discovered that certain operations can break our incremental CI builds. Namely, when a class, for which previously a converter was generated, is removed from the repository. In this case CMake re-generates the dependency rules for the source files of the converter, but since all that changed was that the source files now depend on fewer header files, during the build the converter sources are not re-generated. And we end up with a compilation error, as the previously generated source file is now looking for a header that's no longer available.
To work around this, I had to introduce some manual logic into our CMake configuration that generates a "stamp file" during the CMake configuration using `file(WRITE ...)`, and makes the generation of the converter sources depend on this stamp file. So that we could force re-generating those sources when necessary.
You can find all of this code here:
- https://gitlab.cern.ch/atlas/atlasexternals/blob/master/Build/AtlasCMake/modules/AtlasLibraryFunctions.cmake#L542-575
- https://gitlab.cern.ch/atlas/atlasexternals/blob/master/Build/AtlasCMake/modules/AtlasLibraryFunctions.cmake#L674-692
- Plus a few more instances where `${_stampFile}` is referenced by that same function.
Now, when we generate the build configuration for Ninja, we get warnings like:
```
-- Generating done
CMake Warning (dev):
Policy CMP0058 is not set: Ninja requires custom command byproducts to be
explicit. Run "cmake --help-policy CMP0058" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
This project specifies custom command DEPENDS on files in the build tree
that are not specified as the OUTPUT or BYPRODUCTS of any
add_custom_command or add_custom_target:
Control/DataModelAthenaPool/CMakeFiles/DataModelAthenaPoolPoolCnv.stamp.txt
Database/IOVDbAthenaPool/CMakeFiles/IOVDbAthenaPoolPoolCnv.stamp.txt
Database/PersistentDataModelAthenaPool/CMakeFiles/PersistentDataModelAthenaPoolPoolCnv.stamp.txt
Event/EventAthenaPool/CMakeFiles/EventAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODAssociationsAthenaPool/CMakeFiles/xAODAssociationsAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODBTaggingAthenaPool/CMakeFiles/xAODBTaggingAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODCaloEventAthenaPool/CMakeFiles/xAODCaloEventAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODCaloRingsAthenaPool/CMakeFiles/xAODCaloRingsAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODCoreAthenaPool/CMakeFiles/xAODCoreAthenaPoolPoolCnv.stamp.txt
Event/xAOD/xAODCutFlowAthenaPool/CMakeFiles/xAODCutFlowAthenaPoolPoolCnv.stamp.txt
For compatibility with versions of CMake that did not have the BYPRODUCTS
option, CMake is generating phony rules for such files to convince 'ninja'
to build.
Project authors should add the missing BYPRODUCTS or OUTPUT options to the
custom commands that produce these files.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Build files have been written to: /home/krasznaa/projects/ninja/build
```
When looking for the files in question, right after I get back the prompt, they are all in the place pointed at by these printouts. (In the build/binary directory.)
As I started, I tried to produce a simple, standalone reproducer for this issue. And at first it seemed like I succeeded. I was getting the same sort of warning from an educational example on macOS. But after a few attempts the warning went away... Which makes me very suspicious whether this whole thing is due to `cmake` not recognising some filesystem updates quickly enough. In some cases...
Any hints at how I could solve this, without touching `CMP0058`, would be very helpful. (I don't want to turn off the warnings about non-declared byproducts globally.)
Cheers,
Attilahttps://gitlab.kitware.com/cmake/cmake/-/issues/17554Xerces-c x64 on Windows2017-12-11T18:13:43-05:00Lars SchouwXerces-c x64 on WindowsI can successfully compile Xerces-C x64 with vcpkg but cmake fails to find it.
I suspect there might be a problem with FindXercesC.cmake?
Here are my steps:
1. vcpkg.exe install xerces-c:x64-windows
2. "c:\Program Files (x86)\Microsoft...I can successfully compile Xerces-C x64 with vcpkg but cmake fails to find it.
I suspect there might be a problem with FindXercesC.cmake?
Here are my steps:
1. vcpkg.exe install xerces-c:x64-windows
2. "c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\vc\Auxiliary\Build\vcvars64.bat"
3. cmake .. "-DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake"
It then fails with this error:
CMake Error at C:/installed/cmake-3.9.6-win64-x64/share/cmake-3.9/Modules/FindXercesC.cmake:45 (file):
file STRINGS file
"c:/vcpkg/installed/x86-windows/include/xercesc/util/XercesVersion.hpp"
cannot be read.
Call Stack (most recent call first):
C:/installed/cmake-3.9.6-win64-x64/share/cmake-3.9/Modules/FindXercesC.cmake:87 (_XercesC_GET_VERSION)
C:/vcpkg/scripts/buildsystems/vcpkg.cmake:192 (_find_package)
CMakeLists.txt:6 (find_package)
CMake Error at C:/installed/cmake-3.9.6-win64-x64/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Failed to find XercesC (missing: XercesC_VERSION)
Call Stack (most recent call first):
C:/installed/cmake-3.9.6-win64-x64/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
C:/installed/cmake-3.9.6-win64-x64/share/cmake-3.9/Modules/FindXercesC.cmake:91 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
C:/vcpkg/scripts/buildsystems/vcpkg.cmake:192 (_find_package)
CMakeLists.txt:6 (find_package)
-- Configuring incomplete, errors occurred!
See also "C:/CMakeFiles/CMakeOutput.log".
See also "C:/CMakeFiles/CMakeError.log".https://gitlab.kitware.com/cmake/cmake/-/issues/17553CMAKE_HOST_EXECUTABLE_SUFFIX is needed2023-08-17T00:49:57-04:00Volo ZykoCMAKE_HOST_EXECUTABLE_SUFFIX is needed`CMAKE_EXECUTABLE_SUFFIX` corresponds to executable suffix on target platform but it can be something completely different from the executable suffix in the host's environment. For example, `CMAKE_EXECUTABLE_SUFFIX` when building for Ems...`CMAKE_EXECUTABLE_SUFFIX` corresponds to executable suffix on target platform but it can be something completely different from the executable suffix in the host's environment. For example, `CMAKE_EXECUTABLE_SUFFIX` when building for Emscripten can be either `.html` or `.js`. Other examples, cross-compiling for Windows on Linux and vice versa.
Having single `CMAKE_EXECUTABLE_SUFFIX` (without `CMAKE_HOST_EXECUTABLE_SUFFIX`) makes it difficult to maintain consistent `find_program(FOO_COMMNAD "foo${CMAKE_EXECUTABLE_SUFFIX}")` for host programs.https://gitlab.kitware.com/cmake/cmake/-/issues/17548FindOpenSSL.cmake doesn't respect -m32 flag2023-08-29T10:25:12-04:00apmanolFindOpenSSL.cmake doesn't respect -m32 flagIn CMakeLists.txt:
```
FIND_PACKAGE(OpenSSL REQUIRED)
add_executable(test2 test.cpp)
target_link_libraries(test2 PUBLIC
OpenSSL::SSL OpenSSL::Crypto)
```
Running the cmake command:
```
cmake -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32...In CMakeLists.txt:
```
FIND_PACKAGE(OpenSSL REQUIRED)
add_executable(test2 test.cpp)
target_link_libraries(test2 PUBLIC
OpenSSL::SSL OpenSSL::Crypto)
```
Running the cmake command:
```
cmake -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 ..
make all VERBOSE=1
...
...
usr/bin/cmake -E cmake_link_script CMakeFiles/test2.dir/link.txt --verbose=1
/usr/bin/c++ -m32 CMakeFiles/test2.dir/test.cpp.o -o test2 /usr/lib64/libssl.so /usr/lib64/libcrypto.so
cmake --version
cmake version 3.10.0
```
The make tries to link with the lib64(!) version. `FindBoost.cmake` works as it should and of course there is 32bit OpenSSL version in the system of the library.https://gitlab.kitware.com/cmake/cmake/-/issues/17547Extend support for Windows Universal configurations.2017-12-08T14:12:01-05:00Łukasz KuryłoExtend support for Windows Universal configurations.Right now there is support for WindowsStore applications.
What is lacking is support for Desktop and System WINAPI families, eg. (UMDF v2 drivers).
Support for UWP umbrella libraries is also limitted, current solution is to:
* set(CMA...Right now there is support for WindowsStore applications.
What is lacking is support for Desktop and System WINAPI families, eg. (UMDF v2 drivers).
Support for UWP umbrella libraries is also limitted, current solution is to:
* set(CMAKE_C_STANDARD_LIBRARIES "OneCoreUap.lib" CACHE STRING "" FORCE) <--- Using "FORCE" ;-)
* set(CMAKE_CXX_STANDARD_LIBRARIES "OneCoreUap.lib" CACHE STRING "" FORCE) <--- Using "FORCE" ;-)
* set(MSVC_IGNORED_LIBRARIES "/NODEFAULTLIB:kernel32 /NODEFAULTLIB:advapi32 /NODEFAULTLIB:ole32") <--- Later used in LINKER FLAGS
Extending Platform/Windows-MSVC.cmake to support additional targets beside WINDOWS_STORE or WINDOWS_PHONE would be nice.https://gitlab.kitware.com/cmake/cmake/-/issues/17545FindPkgConfig: don't try multiarch paths on non-multiarch Debian2017-12-07T15:31:14-05:00Ben BoeckelFindPkgConfig: don't try multiarch paths on non-multiarch DebianThe following discussion from !1571 should be addressed:
- [ ] @ben.boeckel commented on a [discussion](https://gitlab.kitware.com/cmake/cmake/merge_requests/1571#note_352175): (+2 comments)
The `FindPkgConfig` module checks if `/etc/...The following discussion from !1571 should be addressed:
- [ ] @ben.boeckel commented on a [discussion](https://gitlab.kitware.com/cmake/cmake/merge_requests/1571#note_352175): (+2 comments)
The `FindPkgConfig` module checks if `/etc/debian_version` exists, but not its version number, to decide whether to do multiarch path support. Older Debian versions should also do the older `lib32` logic.https://gitlab.kitware.com/cmake/cmake/-/issues/17544INSTALL(FILES ${man1} DESTINATION "man/man1") - installs uncompressed manpages2017-12-07T13:17:58-05:00yurivictINSTALL(FILES ${man1} DESTINATION "man/man1") - installs uncompressed manpagesFound the problem on this project https://github.com/drawpile/Drawpile
On FreeBSD, I first patched share/man/man1 -> man/man1 (because this is the standard location).
The statement from the subject installs the uncompressed manpage.
Cha...Found the problem on this project https://github.com/drawpile/Drawpile
On FreeBSD, I first patched share/man/man1 -> man/man1 (because this is the standard location).
The statement from the subject installs the uncompressed manpage.
Changing it to INSTALL(FILES ${man1} DESTINATION "${CMAKE_INSTALL_PREFIX}/man/man1") installs the compressed manpage.
The correct behavior: both should install the compressed manpage because cmake assumes ${CMAKE_INSTALL_PREFIX} when not set.https://gitlab.kitware.com/cmake/cmake/-/issues/17543IMPORTED_LINK_DEPENDENT_LIBRARIES incorrectly populated with private link lib...2017-12-08T15:03:51-05:00Ghost UserIMPORTED_LINK_DEPENDENT_LIBRARIES incorrectly populated with private link librariesWhen a library links against another privately, and we export only the former but not the latter, we would expect the generation step to always succeed.
However, if we have a system library added via e.g. link_libraries(), it is made p...When a library links against another privately, and we export only the former but not the latter, we would expect the generation step to always succeed.
However, if we have a system library added via e.g. link_libraries(), it is made part made of explicitLibraries in cmGeneratorTarget::ComputeLinkInterfaceLibraries(). Hence, also libraries marked as part of the private link interface of the exported library are added to IMPORTED_LINK_DEPENDENT_LIBRARIES as part of cmGeneratorTarget::ComputeLinkInterface().
The attached file acts as a MWE.[CMakeLists.txt](/uploads/1c7dd1a46bbf6976dde74637082ffdea/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/17540Feature Request: Add find_package for targets in INTERFACE_LINK_LIBRARIES in ...2018-12-18T09:26:54-05:00Jason JuangFeature Request: Add find_package for targets in INTERFACE_LINK_LIBRARIES in config filesI am on the latest CMake, Ubuntu 16.04. Suppose I am building a upstream library that depends on an external library that uses targets in their CMake (e.g Boost), so the CMakeLists would look something like.
``````
cmake_minimum_requir...I am on the latest CMake, Ubuntu 16.04. Suppose I am building a upstream library that depends on an external library that uses targets in their CMake (e.g Boost), so the CMakeLists would look something like.
``````
cmake_minimum_required(VERSION 3.9)
project(mysdk)
add_library(${PROJECT_NAME} mylib.h mylib.cpp)
find_package(Boost COMPONENTS filesystem REQUIRED)
target_link_libraries(${PROJECT_NAME} PUBLIC Boost::filesystem)
export(TARGETS FILE ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}Targets.cmake)
file(WRITE ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}Config.cmake
"include(\${CMAKE_CURRENT_LIST_DIR}/${CMAKE_PROJECT_NAME}Targets.cmake)\n")
install(DIRECTORY ${PROJECT_SOURCE_DIR}/include
DESTINATION ${CMAKE_INSTALL_PREFIX}
FILES_MATCHING PATTERN "*.h")
install(FILES ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}Config.cmake
DESTINATION lib/cmake/${CMAKE_PROJECT_NAME})
install(EXPORT ${CMAKE_PROJECT_NAME}Targets NAMESPACE mysdk::
DESTINATION lib/cmake/${CMAKE_PROJECT_NAME})
install(TARGETS ${PROJECT_NAME}
EXPORT ${CMAKE_PROJECT_NAME}Targets
ARCHIVE DESTINATION ${CMAKE_INSTALL_PREFIX}/lib
LIBRARY DESTINATION ${CMAKE_INSTALL_PREFIX}/lib
RUNTIME DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
``````
After `mysdk` is built and installed, inside `mysdkTargets.cmake` there will be something like
```
# Create imported target mysdk::mysdk
add_library(mysdk::mysdk IMPORTED)
set_target_properties(mysdk::mysdk PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "/usr/local/include;/usr/local/include"
INTERFACE_LINK_LIBRARIES "Boost::filesystem"
INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "/usr/local/include"
)
```
When I try to use the upstream library `mysdk` in my downstream project, I ran into the problem where I had to add `find_package(Boost COMPONENTS filesystem REQUIRED)` in my CMakeLists otherwise there will be a target `Boost::filesystem` unrecognized error. See below example CMakeLists
``````
cmake_minimum_required(VERSION 3.9)
project(myproject)
add_executable(${PROJECT_NAME} main.cpp)
find_package(Boost COMPONENTS filesystem REQUIRED) # this line is needed otherwise there will be error
find_package(mysdk REQUIRED)
target_link_libraries(${PROJECT_NAME} PUBLIC mysdk::mysdk)
``````
IMO for a smoother experience for the user of the downstream projects, it would make sense to completely abstract away the boost dependency into `mysdkTargets.cmake`. An obvious way to achieve this is somehow embed the `find_package(Boost COMPONENTS filesystem REQUIRED)` into `mysdkTargets.cmake`. Could we add this feature in future CMake releases?https://gitlab.kitware.com/cmake/cmake/-/issues/17537The QCC CXX toolchain does not set CMAKE_CXXnn_STANDARD_COMPILE_OPTIONs and f...2017-12-06T10:57:30-05:00Ghost UserThe QCC CXX toolchain does not set CMAKE_CXXnn_STANDARD_COMPILE_OPTIONs and friendsWhile Modules/Compiler/GNU-CXX.cmake handles CMAKE_CXX98_STANDARD_COMPILE_OPTION and friends, the QNX toolchain does not. See Modules/Compiler/QCC-CXX.cmake.
This breaks trying to set a C++ standard via target_compile_features, or even ...While Modules/Compiler/GNU-CXX.cmake handles CMAKE_CXX98_STANDARD_COMPILE_OPTION and friends, the QNX toolchain does not. See Modules/Compiler/QCC-CXX.cmake.
This breaks trying to set a C++ standard via target_compile_features, or even through the CXX_STANDARD target property.https://gitlab.kitware.com/cmake/cmake/-/issues/17536specify Environment variables for externalproject2023-01-07T21:39:17-05:00Evgeniy Dushistovspecify Environment variables for externalprojectIt would be great to add ability to specify Environment variables for `ExternalProject_Add` and `ExternalProject_Add_Step`,It would be great to add ability to specify Environment variables for `ExternalProject_Add` and `ExternalProject_Add_Step`,https://gitlab.kitware.com/cmake/cmake/-/issues/17528Visual Studio: Unnecessary compile dependencies w/ target_link_libraries2017-12-01T09:58:00-05:00Donal MacCarthyVisual Studio: Unnecessary compile dependencies w/ target_link_librariesHi - This is related to https://gitlab.kitware.com/cmake/cmake/issues/15555 but with a different generator. We're using the VS2015 Generator, and have the exact same problem.
Using a slightly different `CMakeLists.txt` file;
proj...Hi - This is related to https://gitlab.kitware.com/cmake/cmake/issues/15555 but with a different generator. We're using the VS2015 Generator, and have the exact same problem.
Using a slightly different `CMakeLists.txt` file;
project(libDependencyTest C)
add_library ( a STATIC a.c )
target_include_directories(a PUBLIC "A")
target_compile_definitions(a PUBLIC A_DEFINE=1)
# b.c includes a file in "A", and uses A_DEFINE=1
add_library ( b STATIC b.c )
target_link_libraries ( b a )
add_executable ( e e.c )
target_link_libraries ( e b )
Generating for Visual Studio with `cmake -H. -Bbuild -G"Visual Studio 14 2015 Win64"` and opening the solution tells me that:
`e` depends on `a` and `b`
`b` depends on `a` (which is unnecessary)
This is a problem for us for the same reason it was a problem in 15555 - our build time is getting very long, we have very parallel developer machines, but our builds appear to be practically serial.
I've tried implementing my own function `add_soft_dependency` that looks like this
function(add_soft_dependency target)
foreach(arg ${ARGN})
target_link_libraries(${target} INTERFACE ${arg})
target_include_directories(${target} PUBLIC $<TARGET_PROPERTY:${arg},INCLUDE_DIRECTORIES>)
target_compile_definitions(${target} PUBLIC $<TARGET_PROPERTY:${arg},COMPILE_DEFINITIONS>)
endforeach()
endfunction()
and then using it for the dependency between `b` and `a`, but it's generating invalid VS projects for us (with non-ascii characters in it), which means it's unusable.
Verified with cmake 3.7 and with cmake 3.10https://gitlab.kitware.com/cmake/cmake/-/issues/17524Ninja: re-compilation cascades in Fortran builds2023-09-06T15:58:17-04:00Yurii BatrakNinja: re-compilation cascades in Fortran buildsWhen cmake uses the "Unix Makefiles" generator it produces a makefile that contains some additional "magic" to avoid unnecessary re-compilations. Basically, when a Fortran module is re-compiled, cmake checks, does the produced `*.mod` fi...When cmake uses the "Unix Makefiles" generator it produces a makefile that contains some additional "magic" to avoid unnecessary re-compilations. Basically, when a Fortran module is re-compiled, cmake checks, does the produced `*.mod` file differ from the `*.mod` file from previous compilation, and is able to figure out that modules are actually the same.
Contrary, when cmake uses the "Ninja" generator such optimization isn't applied and if Fortran compiler updates timestamps of module files on each re-compilation, even if the `*.mod` file itself wasn't changed (as in case of ifort), an incremental build with ninja falls in a series of unnecessary re-compilations.https://gitlab.kitware.com/cmake/cmake/-/issues/17521How to create a 64-bit build and AnyCPU build of a c# project through CMake2023-12-08T16:14:55-05:00shaguftaHow to create a 64-bit build and AnyCPU build of a c# project through CMakeHow to build a C# solution in x86 and AnyCPU architecture ?
How to change the platform target of a project/target through CMake ?
Even if the build platform of the solution is changed to example:x86 the platform target of the project/t...How to build a C# solution in x86 and AnyCPU architecture ?
How to change the platform target of a project/target through CMake ?
Even if the build platform of the solution is changed to example:x86 the platform target of the project/target remains x64 as default .Michael StürmerMichael Stürmerhttps://gitlab.kitware.com/cmake/cmake/-/issues/17520CUDA: Device link not enabled for library target in VS20172018-04-27T10:43:25-04:00Lin HsuCUDA: Device link not enabled for library target in VS2017* CMake: 3.10.0
* CUDA: 9.0
* OS: Windows 10
* VS: 2017
* Testing project: https://github.com/chaosink/cupix
### Some facts:
Library targets **don't** enable device link (`CUDA Linker` option in VS) no matter `CUDA_SEPARABLE_COMPILATIO...* CMake: 3.10.0
* CUDA: 9.0
* OS: Windows 10
* VS: 2017
* Testing project: https://github.com/chaosink/cupix
### Some facts:
Library targets **don't** enable device link (`CUDA Linker` option in VS) no matter `CUDA_SEPARABLE_COMPILATION` is `ON` or `OFF`.
Executable targets **always** enable device link no matter `CUDA_SEPARABLE_COMPILATION` is `ON` or `OFF`.
### Problem:
For the example project in the [article](https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/), the library target `particle` without device link is OK, because the executable target `particle_test` also has `.cu` files. So nvcc will be called to link `particle` and `particle_test` with `-dlink`.
However, if the executable target `particle_test` doesn't have `.cu` files (for example the [tesing project](https://github.com/chaosink/cupix)), nvcc will not be called so the library `particle` will not do device link. This will cause the common error `__cudaRegisterLinkedBinary` in the final link.
For the testing project, I have to enable device link manually for the library target in VS `CUDA Linker`.
Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/17516C++11 nmake configuration fails for latest MS C++ compiler2017-11-29T04:52:53-05:00BeErikkC++11 nmake configuration fails for latest MS C++ compiler**Environment**
OS: Windows 10
Compiler: Microsoft C/C++ Compiler Version 19.11.25547 for x64 (VS2017 15.4.4)
cmake version: 3.10.0 release Windows x64
**Description**
Running cmake configuration for nmake makefile generation on C++11 s...**Environment**
OS: Windows 10
Compiler: Microsoft C/C++ Compiler Version 19.11.25547 for x64 (VS2017 15.4.4)
cmake version: 3.10.0 release Windows x64
**Description**
Running cmake configuration for nmake makefile generation on C++11 source (ie current git cmake source), using latest MS C++ compiler toolchain, fails with the message:
```
CMake Error at CMakeLists.txt:79 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
```
the only error I can find in the logs is:
`cm_cxx_fallthrough.cxx(7): error C2429: attribute 'fallthrough' requires compiler flag '/std:c++latest'`
all other tests seem to work AFAICS
**How to reproduce**
run cmake 3.10.0 on cmake current git source with `nmake` generation and specify MS Compiler 19.11.25547https://gitlab.kitware.com/cmake/cmake/-/issues/17513Allow setting the --graphviz="path" option via CMake script variable.2017-11-27T04:42:54-05:00KnitschiAllow setting the --graphviz="path" option via CMake script variable.This is a feature request.
In my project I am using the `--graphviz` option per default, because I have a custom target that uses the generated files to check for circular dependencies between targets. It would shorten the command line ...This is a feature request.
In my project I am using the `--graphviz` option per default, because I have a custom target that uses the generated files to check for circular dependencies between targets. It would shorten the command line if the option could also be set with a variable in the CMakeLists.txt file to remove the need for adding the option on each command line call.
Cheers Knitschihttps://gitlab.kitware.com/cmake/cmake/-/issues/17509ExternalProject_Add URL requires higher permissions than needed to copy?2017-11-27T12:23:44-05:00SocapexExternalProject_Add URL requires higher permissions than needed to copy?If I point an ExternalProject_Add command to a local directory, with the external project's VS solution open, cmake will fail to copy the directory.
[Win 10 Enterprise N, 1709, 64bit]If I point an ExternalProject_Add command to a local directory, with the external project's VS solution open, cmake will fail to copy the directory.
[Win 10 Enterprise N, 1709, 64bit]https://gitlab.kitware.com/cmake/cmake/-/issues/17504Cmake build x265 FAILED:LINK : fatal error LNK1181: cannot open input file '....2017-11-22T04:15:11-05:00hanbing001Cmake build x265 FAILED:LINK : fatal error LNK1181: cannot open input file '..\x265_2.5\build\vc10-x86_64\pixel-a.asm.obj'The problem is like this,
https://bitbucket.org/multicoreware/x265/issues/205/build-with-assembly-enabled-fails-with
The fault is : LINK : fatal error LNK1181: cannot open input file '..\x265_2.5\build\vc10-x86_64\pixel-a.asm.obj'
But t...The problem is like this,
https://bitbucket.org/multicoreware/x265/issues/205/build-with-assembly-enabled-fails-with
The fault is : LINK : fatal error LNK1181: cannot open input file '..\x265_2.5\build\vc10-x86_64\pixel-a.asm.obj'
But the generated file is named 'pixel-a.obj'.
I am using cmake-3.10.0-win64-x64,and I want to know how to solve this problem.