CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-03-01T12:44:31-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/17448Ninja and Make run linker from different directories2018-03-01T12:44:31-05:00Sebastian BøeNinja and Make run linker from different directoriesHi,
I noticed that CMake "invokes" the linker from different directories with Ninja and Make.
This is fine for most use-cases. Because CMake will change all paths passed to the linker
appropriately.
But this will go horribly wrong if ...Hi,
I noticed that CMake "invokes" the linker from different directories with Ninja and Make.
This is fine for most use-cases. Because CMake will change all paths passed to the linker
appropriately.
But this will go horribly wrong if a custom linker script is used and this linker script
is using relative paths to libraries.
For my particular use-case I can (and should) rewrite the linker script to support being
invoked from different directories, but wouldn't it be desired behaviour to be consistent
across generators?
To reproduce:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
add_subdirectory(sub)
# sub/CMakeLists.txt
add_executable(app main.c)
# Make output:
cd /home/sebo/workspace_zephyr/ninja_vs_make/b/sub && /home/sebo/zephyr/samples/bluetooth/mesh/a/cmake-3.10.0-rc4-Linux-x86_64/bin/cmake -E cmake_link_script CMakeFiles/app.dir/link.txt --verbose=1
/usr/bin/cc CMakeFiles/app.dir/main.c.o -o app
# Ninja output:
ninja: Entering directory `n/'
[1/1] : && /usr/bin/cc sub/CMakeFiles/app.dir/main.c.o -o sub/app && :https://gitlab.kitware.com/cmake/cmake/-/issues/17447Using dpkg-shlibdeps to find dependencies while building multi component deb-...2022-11-17T14:34:55-05:00Ivan SudakovUsing dpkg-shlibdeps to find dependencies while building multi component deb-packageHi!
I'm building deb-package with two components: libs and examples. Examples executables depend on shared libraries in libs package
Can CPack find such dependencies?
I'm getting error during build: dpkg-shlibdeps can't find my librar...Hi!
I'm building deb-package with two components: libs and examples. Examples executables depend on shared libraries in libs package
Can CPack find such dependencies?
I'm getting error during build: dpkg-shlibdeps can't find my libraries from lib component and I don't understand how can it work because file "shlibs" for my libraries exists only in build directory
My code to enable dependencies generation:
set(CPACK_DEBIAN_PACKAGE_DEBUG ON)
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/17445`/` special case in CMAKE_INSTALL_PREFIX is inconsistent with autoconf2019-03-01T09:14:56-05:00Keno Fischer`/` special case in CMAKE_INSTALL_PREFIX is inconsistent with autoconfHi folks,
this is about the special cases in CMAKE_INSTALL_PREFIX introduced by https://github.com/Kitware/CMake/commit/c8bd37ec685c02736618af83ac894e96fc1e6ab8.
In particular, I'm not a fan of automatically rewriting the `/` to `/usr`....Hi folks,
this is about the special cases in CMAKE_INSTALL_PREFIX introduced by https://github.com/Kitware/CMake/commit/c8bd37ec685c02736618af83ac894e96fc1e6ab8.
In particular, I'm not a fan of automatically rewriting the `/` to `/usr`. The justification
given is that GNU states that
When building the complete GNU system, the prefix will be empty
# and ``/usr`` will be a symbolic link to ``/``.
which to me doesn't justify the this special case. Moreover, it's inconsistent with GNU autoconf,
e.g.
```
./configure --prefix=/
make
make install DESTDIR=/foo/bar
```
will install things in `/foo/bar/{bin,lib,...}`, while for CMake, after that commit, commands like
```
cmake -DCMAKE_INSTALL_PREFIX=/
make
make install DESTDIR=/foo/bar
```
will end up in `/foo/bar/usr/{bin,lib,...}`. There also doesn't really seem to be a good way to disable
this behavior other than setting each of the individual directories to an absolute path, which I hope
you will agree with me is not a very nice solution. Now, you might wonder why I care about this, since
```
cmake -DCMAKE_INSTALL_PREFIX=/foo/bar
make
make install
```
would ostensibly do what I want. However, there's a subtle distinction between this command and the
previous. The primary difference here is moving that install to a target machine. The prefix is supposed
to refer to the target machine's layout (which in my case does not use /usr), and some build processes do
rely on that by embedding prefix-derived paths into the resulting binaries, which would fail for the
`/foo/bar` case. I recognize that at this point it might be too late to remove that special case, but
I'd love to at least have some way to specify at the
command line that no, really, I do want / to be my prefix.https://gitlab.kitware.com/cmake/cmake/-/issues/17442FindHDF5 always finds 64-bit libraries on 64/32 multilib systems2017-11-08T07:16:37-05:00William ThroweFindHDF5 always finds 64-bit libraries on 64/32 multilib systems`find_package(HDF5)` would find 32- or 64-bit libraries as appropriate on a multilib system in cmake-3.7.2, but always finds 64-bit libraries in 3.8.2 (and on current master). By bisecting I've tracked this down to 77f6d22ad1f1b461297a...`find_package(HDF5)` would find 32- or 64-bit libraries as appropriate on a multilib system in cmake-3.7.2, but always finds 64-bit libraries in 3.8.2 (and on current master). By bisecting I've tracked this down to 77f6d22ad1f1b461297a463eb5f40fbb0d0825aa, which (probably accidentally), changed the `find_libraries` calls from taking a PATHS argument to taking a HINTS argument.
Changing the HINTS back to PATHS on master allows finding 32-bit libraries again, although I am not sure which type of argument `${HDF5_ROOT}` should be.https://gitlab.kitware.com/cmake/cmake/-/issues/17441Feature Request: CMake autoformatter and linter2019-01-30T17:26:47-05:00Jason JuangFeature Request: CMake autoformatter and linterIn the case of C++ code, there is clang-format (https://clang.llvm.org/docs/ClangFormat.html) that automatically formats the code to enforce a consistent coding style, which is a huge huge pain reduction when reading other people's code....In the case of C++ code, there is clang-format (https://clang.llvm.org/docs/ClangFormat.html) that automatically formats the code to enforce a consistent coding style, which is a huge huge pain reduction when reading other people's code. There is also linters like cpplint (https://en.wikipedia.org/wiki/Cpplint) that will "remind" the developer when their code is not following a certain style.
To my knowledge, there is an unofficial CMake linter called cmakelint https://github.com/richq/cmake-lint, but the style checks are rather basic.
I am wondering whether CMake has plans to release an autoformatter or a linter for CMakeLists? That will reduce a lot of pain when reading other people's CMakeLists. Please consider this!https://gitlab.kitware.com/cmake/cmake/-/issues/17438How to add a link tag within Compile tag of .csproj file using CMAKE2017-11-14T12:00:43-05:00shaguftaHow to add a link tag within Compile tag of .csproj file using CMAKEI need to include a link to a CommonAssemblyInfo.cs file with in the Properties folder of a Project/Target , how do I achive the same in CMakeLists.txt file ?
(CommonAssemblyInfo.cs file is located outside the src folder)
after CMAKE gen...I need to include a link to a CommonAssemblyInfo.cs file with in the Properties folder of a Project/Target , how do I achive the same in CMakeLists.txt file ?
(CommonAssemblyInfo.cs file is located outside the src folder)
after CMAKE generation my .csprojectfile shoud look like this :
<ItemGroup>
<Compile Include="..\..\CommonAssemblyInfo.cs">
<Link>Properties\CommonAssemblyInfo.cs</Link>
</Compile>
</ItemGroup>
Thanks
@shaguftahttps://gitlab.kitware.com/cmake/cmake/-/issues/17428CMake Xcode attributes are not set correctly when one project is a subproject...2017-11-06T12:24:40-05:00Adam KitchingCMake Xcode attributes are not set correctly when one project is a subproject of anotherWhen I set xcode attributes in a cmake project such as
```cmake
set(CMAKE_XCODE_ATTRIBUTE_VALID_ARCHS "x86_x64")
```
they are set correctly when I build that project. However, if I make another project that sits above that project, suc...When I set xcode attributes in a cmake project such as
```cmake
set(CMAKE_XCODE_ATTRIBUTE_VALID_ARCHS "x86_x64")
```
they are set correctly when I build that project. However, if I make another project that sits above that project, such as with a CMakeLists.txt that does
```cmake
cmake_minimum_required(VERSION 2.8)
project(all)
add_subdirectory(project1)
add_subdirectory(project2)
```
The attributes will not be set correctly for the subprojects when you look at the settings in Xcode, they appear to be using the Xcode defaults in this case. I have tried this with a few different attributes and they all seem to exhibit the same problem.
I have created a simple repro file attached. Generate project1 or project2, and the Valid Archs setting will be set correctly, but if you generate the 'all' project above it, it will be the default for all projects.
[cmakeProb.zip](/uploads/0d1cafee92b2ecc74bc733f7eb47869f/cmakeProb.zip)
This is tested with 3.10RC.
Thanks!Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17425ctest build returns success exit code when out-of-memory2017-11-08T03:17:06-05:00nctest build returns success exit code when out-of-memoryWhen compiling with `ctest -T Build`, if the ram is full and generates a out-of-memory, ctest exits with a `0` exit code and does not generate any error.
This silent problem is hard to track when looking at the result on cdash.
Would it ...When compiling with `ctest -T Build`, if the ram is full and generates a out-of-memory, ctest exits with a `0` exit code and does not generate any error.
This silent problem is hard to track when looking at the result on cdash.
Would it be possible to explicitly track out-of-memory and return a specific error code?
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/17423INTERPROCEDURAL_OPTIMIZATION using Makefiles under MacOS2017-11-01T11:19:34-04:00Phillip KeldenichINTERPROCEDURAL_OPTIMIZATION using Makefiles under MacOSIn a C++ project on MacOS built using the Unix Makefiles generator, the call to check_ipo_supported seems to build a target `foo`. Building that target uses CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB; these are set to NOTFOUND.
...In a C++ project on MacOS built using the Unix Makefiles generator, the call to check_ipo_supported seems to build a target `foo`. Building that target uses CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB; these are set to NOTFOUND.
Other than this, building the entire project works fine (so CMake actually finds ar and ranlib or is, at least, able to build static and dynamic libraries and executables).
I use the following code to detect support for interprocedural optimization.
```cmake
set(_UTIL_IPO_SUPPORTED FALSE)
if(${CMAKE_MAJOR_VERSION} GREATER 2 AND ${CMAKE_MINOR_VERSION} GREATER 8)
cmake_policy(SET CMP0069 NEW)
include(CheckIPOSupported)
check_ipo_supported(RESULT _UTIL_IPO_SUPPORTED OUTPUT _UTIL_IPO_UNSUPPORTED_ERROR LANGUAGES CXX)
if(NOT _UTIL_IPO_SUPPORTED)
message(STATUS "Interprocedural/link-time optimization not supported: ${_UTIL_IPO_UNSUPPORTED_ERROR}")
endif()
endif()
```
This produces an error message that boils down to the detection script trying to run CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB, both set to NOTFOUND, resulting in a no-such-command error.
Setting CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB manually by passing -D... to cmake works as intended - IPO detection is successful and the appropriate flags are added to all targets with the corresponding property set.Ruslan Baratovx@ruslo.devRuslan Baratovx@ruslo.devhttps://gitlab.kitware.com/cmake/cmake/-/issues/17420Cmake fails to identify the compiler with clean install of Visual Studio 2017...2017-12-04T13:18:21-05:00Adrien EscandeCmake fails to identify the compiler with clean install of Visual Studio 2017 (15.4.2)On a brand new computer with Windows 10 pro, I installed
- Visual Studio Community 2017, Version 15.4.2, including the Windows 10 SDK
- the latest version of CMake (tried 3.9.4 and 3.10.06rc3)
both with default installation paths.
Cmak...On a brand new computer with Windows 10 pro, I installed
- Visual Studio Community 2017, Version 15.4.2, including the Windows 10 SDK
- the latest version of CMake (tried 3.9.4 and 3.10.06rc3)
both with default installation paths.
Cmake fails with the following message
```
The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error in CMakeLists.txt:
No CMAKE_C_COMPILER could be found.
CMake Error in CMakeLists.txt:
No CMAKE_CXX_COMPILER could be found.
```
where the error is due to not finding `gdi32.lib` while attempting to compile `CompilerIdC` and `CompilerIdCXX`:
```
LINK : fatal error LNK1181: cannot open input file 'gdi32.lib'
```
This library (and the other set in `CMAKE_C_STANDARD_LIBRARIES_INIT`) is present on my system: when editing by hand CompilerIdC.vcxproj to include the path of the libraries ("C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x64"), I can compile the project with Visual Studio.
I didn't manage to set up my environment variables to work around this problem, but anyhow, I would not expect CMake to have me play with that in order to work.https://gitlab.kitware.com/cmake/cmake/-/issues/17419cmake 3.5.1 fails to track dependencies on include files where the file name ...2019-02-20T17:21:49-05:00Franz Hollerercmake 3.5.1 fails to track dependencies on include files where the file name is given as macroI use the following construct:
```cpp
#include "user_config.h"
#include CONFIG_USER_TARGET_INCLUDE
:
:
```
The user customizes the build by specifying the include file as macro. I use this approach to avoid circular dependencies, and ...I use the following construct:
```cpp
#include "user_config.h"
#include CONFIG_USER_TARGET_INCLUDE
:
:
```
The user customizes the build by specifying the include file as macro. I use this approach to avoid circular dependencies, and it works fine so far. Another use case could be https://stackoverflow.com/questions/4743822/generate-include-file-name-in-a-macro.
Unfortunately, cmake failed to track the dependencies when I use a macro. The source file is not recompiled when the include files specified as macro is changed. I tried several thinks like add_dependencies(), add_custom_command(), etc. but non of them worked.
Please can you add support for this use case in an upcoming version.https://gitlab.kitware.com/cmake/cmake/-/issues/17417macro for exporting templates in msvc2017-10-30T16:18:35-04:00T.J. Coronamacro for exporting templates in msvcI was looking through [Microsoft's support pages for exporting template instantiations](https://support.microsoft.com/en-us/help/168958/how-to-export-an-instantiation-of-a-standard-template-library-stl-clas), and I noticed that they defi...I was looking through [Microsoft's support pages for exporting template instantiations](https://support.microsoft.com/en-us/help/168958/how-to-export-an-instantiation-of-a-standard-template-library-stl-clas), and I noticed that they define a macro for import/export declspec (like CMake does) and a macro for import/export template instantiations (which I don't think Cmake does). Does it make sense for CMake to also define a macro for this purpose?https://gitlab.kitware.com/cmake/cmake/-/issues/17416Libraries link order for INTERFACE IMPORTED targets2017-10-31T07:08:46-04:00JamesLibraries link order for INTERFACE IMPORTED targetsFrom: https://github.com/conan-io/conan/issues/1875
The issue is that when building a higher level of abstraction for packages, in which each package is an INTERFACE IMPORTED target (as they don't come from the same project), the follow...From: https://github.com/conan-io/conan/issues/1875
The issue is that when building a higher level of abstraction for packages, in which each package is an INTERFACE IMPORTED target (as they don't come from the same project), the following graph (=> means depends on) is built:
```
TargetA (INTERFACE IMPORTED) => TargetB (INTERFACE IMPORTED)
TargetA => LibA.a (item)
TargetB => LibB.a (item)
```
Then, the final relative order obtained is ``TargetA, TargetB, LibB.a, LibA.a``, producing a link error, instead of the expected one ``TargetA, TargetB, LibA.a, LibB.a``. Even if the former seems to make sense for the graph, the second one would be the expected one if considering that they are INTERFACE IMPORTED targets, and thus acting as proxies of the real libraries.https://gitlab.kitware.com/cmake/cmake/-/issues/17415Add column character ':' as valid character for command and variable identifiers2017-10-30T10:45:27-04:00Marc ChevrierAdd column character ':' as valid character for command and variable identifiersCurrently, there is an inconsistency between targets and commands, variables regarding valid characters.
targets can have character ':' as part of their name (very useful for imported targets) but this character is invalid for command an...Currently, there is an inconsistency between targets and commands, variables regarding valid characters.
targets can have character ':' as part of their name (very useful for imported targets) but this character is invalid for command and variable names.
Adding the character ':' as valid for commands and variables will enable to homogenize symbols exported by modules: targets, commands and variables will all have the same namespace prefix.https://gitlab.kitware.com/cmake/cmake/-/issues/17414qt4_wrap_cpp didn't include common moc options in per-config parameter file2018-01-13T07:19:55-05:00comicfansqt4_wrap_cpp didn't include common moc options in per-config parameter fileI'm using qt4_wrap_cpp(moc_srcs MyDialog.h TARGET Qt4::QtGui) to generate moc files, but found compile definitions of Qt4::QtGui (-DQT_GUI_LIB) only goes into common parameter file
moc_MyDialog.cxx_parameters
but didn't appears in per-c...I'm using qt4_wrap_cpp(moc_srcs MyDialog.h TARGET Qt4::QtGui) to generate moc files, but found compile definitions of Qt4::QtGui (-DQT_GUI_LIB) only goes into common parameter file
moc_MyDialog.cxx_parameters
but didn't appears in per-config parameter file moc_MyDialog.cxx_parameters_RelWithDebInfo,
and ninja generator generated commands to run moc is
D:\qt\bin\moc.exe @D:/xxx/moc_MyDialog.cxx_parameters_RelWithDebInfo
this leads incorrect define options when building moc files.
version is 3.10.0-rc2
---update----
I might try different cmake file multi times( with qt4_wrap_cpp(mocs header.h TARGET Qt4::QtGui) and qt4_wrap_cpp(mocs header.h OPTIONS -DQT_GUI_LIB) ) , so "compile definitions of Qt4::QtGui(-DQT_GUI_LIB) only goes into common parameter file" may not be true. when I test this in a demo project, I found if using
qt4_wrap_cpp(mocs header.h TARGET Qt4::QtGui)
neither common file nor per-config file contains these flags.https://gitlab.kitware.com/cmake/cmake/-/issues/17413CrayPrgEnv.cmake mishandles CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES2019-02-08T16:59:47-05:00chuck cranorCrayPrgEnv.cmake mishandles CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIESGCC 6 and newer changed their include files so that if you compile a C++ program with "-isystem /usr/include" it fails with "stdlib.h: No such file or directory"... see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
and
https://git...GCC 6 and newer changed their include files so that if you compile a C++ program with "-isystem /usr/include" it fails with "stdlib.h: No such file or directory"... see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
and
https://gitlab.kitware.com/cmake/cmake/issues/16291
One of our cmake-based projects is impacted by this on the Cray, so I stated looking at the CrayPrgEnv.cmake to see exactly what it is doing and I found several problems in the cmake code:
1. The function __cray_extract_implicit's first arg is ${src}. ${src} is the name of a source file to do a test compile with (e.g. "cc -v" or "c++ -v"). For CXX the CrayPrgEnv-CXX.cmake sets this to "${CMAKE_ROOT}/Modules/CMakeCXXCompilerABI.cpp"... Unfortunately, the __cray_extract_implicit function doesn't actually use the ${src} variable anywhere in the body of the function! This results in the output of execute_process() being incomplete (e.g. it does not contain any INCLUDE information). Thus, when you run "cmake" on a Cray with CrayPrgEnv the ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES} is incorrectly empty. The fix for this is to add "${src}" after "-o ${BIN}" in the COMMAND part of the call to execute_process().
2. if you manually fix the handling of ${src} in __cray_extract_implicit() as suggested above, you will get a partial (but incomplete!) list of includes in ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES}. This is because __cray_extract_implicit()'s handling is incorrect. The code uses a regular expression in ${compiler_command} to look for a line like "/opt/gcc/.*/cc1plus" (or "/opt/gcc/.*/cc1" for C) to extract -I's from the line to generate the implicit include list. Unfortunately, this line does not include important directories like /usr/include in the list. But that information is included later on in the output between the lines "#include <...> search starts here:" and "End of search list." ... the output parsing in CrayPrgEnv.cmake needs to be adjusted to handle this. Here is some sample output from the GNU C compiler on a Cray:
```
/opt/gcc/7.1.0/snos/libexec/gcc/x86_64-suse-linux/7.1.0/cc1 -quiet -v -I /opt/cray/pe/libsci/17.09.1/GNU/6.1/x86_64/include -I /opt/cray/pe/mpt/7.6.2/gni/mpich-gnu/5.1/include -I /opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/include -I /opt/cray/alps/6.4.1-6.0.4.0_7.2__g86d0f3d.ari/include -I /opt/cray/xpmem/2.2.2-6.0.4.0_3.1__g43b0535.ari/include -I /opt/cray/gni-headers/5.0.11-6.0.4.0_7.2__g7136988.ari/include -I /opt/cray/pe/pmi/5.0.12/include -I /opt/cray/ugni/6.0.14-6.0.4.0_14.1__ge7db4a2.ari/include -I /opt/cray/udreg/2.3.2-6.0.4.0_12.2__g2f9c3ee.ari/include -I /opt/cray/wlm_detect/1.2.1-6.0.4.0_22.1__gd26a3dc.ari/include -I /opt/cray/krca/2.2.2-6.0.4.0_5.2__g4614cf3.ari/include -I /opt/cray-hss-devel/8.0.0/include -D __CRAYXC -D __CRAY_HASWELL -D __CRAYXT_COMPUTE_LINUX_TARGET -D __TARGET_LINUX__ /users/ccranor/tmp/cmake/share/cmake-3.10/Modules/CMakeCCompilerABI.c -quiet -dumpbase CMakeCCompilerABI.c -march=core-avx2 -auxbase CMakeCCompilerABI -version -o /tmp/ccsd57Wh.s
GNU C11 (GCC) version 7.1.0 20170502 (Cray Inc.) (x86_64-suse-linux)
compiled by GNU C version 7.1.0 20170502 (Cray Inc.), GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version isl-0.15-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/gcc/7.1.0/snos/lib/gcc/x86_64-suse-linux/7.1.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/cray/pe/libsci/17.09.1/GNU/6.1/x86_64/include
/opt/cray/pe/mpt/7.6.2/gni/mpich-gnu/5.1/include
/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/include
/opt/cray/alps/6.4.1-6.0.4.0_7.2__g86d0f3d.ari/include
/opt/cray/xpmem/2.2.2-6.0.4.0_3.1__g43b0535.ari/include
/opt/cray/gni-headers/5.0.11-6.0.4.0_7.2__g7136988.ari/include
/opt/cray/pe/pmi/5.0.12/include
/opt/cray/ugni/6.0.14-6.0.4.0_14.1__ge7db4a2.ari/include
/opt/cray/udreg/2.3.2-6.0.4.0_12.2__g2f9c3ee.ari/include
/opt/cray/wlm_detect/1.2.1-6.0.4.0_22.1__gd26a3dc.ari/include
/opt/cray/krca/2.2.2-6.0.4.0_5.2__g4614cf3.ari/include
/opt/cray-hss-devel/8.0.0/include
/opt/gcc/7.1.0/snos/lib/gcc/x86_64-suse-linux/7.1.0/include
/usr/local/include
/opt/gcc/7.1.0/snos/include
/opt/gcc/7.1.0/snos/lib/gcc/x86_64-suse-linux/7.1.0/include-fixed
/usr/include
End of search list.
GNU C11 (GCC) version 7.1.0 20170502 (Cray Inc.) (x86_64-suse-linux)
compiled by GNU C version 7.1.0 20170502 (Cray Inc.), GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3, isl version isl-0.15-GMP
```
Note that the last 5 includes (from "/opt/gcc/7.1.0/snos/lib/gcc/x86_64-suse-linux/7.1.0/include" to "/usr/include" are not in the "cc1" output line.
3. the CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES variable is not preserved between runs. It isn't a cache variable and it isn't saved in the output directory file:
"CMakeFiles/*/CmakeCXXCompiler.cmake" either. On CrayPrgEnv.cmake, this results in the include processing being done the first time you run cmake, but then not on later times (because the CRAY_<LANG>_EXTRACTED_IMPLICIT cache variable is set to 1). Because UnixPaths.cmake init's the value to "/usr/include" if you rerun cmake it gets set to "/usr/include" instead of the correct value. I believe that files like "Modules/CMakeCXXCompiler.cmake.in" should be modified to include CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES in the list of data that they preserve between runs. I tried this, and it works (although it has an extra copy of /usr/include in the path... I think one is from the CrayPrgEnv and the other is the one that UnixPaths appends).
Here is a demo of the problem using a simple CMakeLists.txt on a cray:
```
cmake_minimum_required (VERSION 3.5)
project (cray-test C CXX)
message ("STATUS: incdir: ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES}")
message ("STATUS: lnkdir: ${CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES}")
message ("STATUS: lnklib: ${CMAKE_CXX_IMPLICIT_LINK_LIBRARIES}")
```
Here's the output from 3.6.2 on a Cray:
```
% cmake --version
cmake version 3.6.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
%
%
% env CC=cc CXX=CC cmake ..
-- The C compiler identification is Intel 17.0.4.20170411
-- The CXX compiler identification is Intel 17.0.4.20170411
-- Cray Programming Environment 2.5.12 C
-- Check for working C compiler: /opt/cray/pe/craype/2.5.12/bin/cc
-- Check for working C compiler: /opt/cray/pe/craype/2.5.12/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment 2.5.12 CXX
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.12/bin/CC
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.12/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
STATUS: incdir:
STATUS: lnkdir: /opt/cray/pe/libsci/17.09.1/INTEL/16.0/x86_64/lib;/opt/cray/dmapp/default/lib64;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/lib;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/lib64;/opt/cray/pe/atp/2.1.1/libApp;/opt/intel/2017.4.196/compilers_and_libraries_2017/linux/mkl/lib/intel64;/opt/intel/2017.4.196/compilers_and_libraries_2017.4.196/linux/compiler/lib/intel64_lin;/opt/gcc/6.3.0/snos/lib/gcc/x86_64-suse-linux/6.3.0;/opt/gcc/6.3.0/snos/lib64;/lib64;/usr/lib64;/opt/gcc/6.3.0/snos/lib;/lib;/usr/lib
STATUS: lnklib: intlc;AtpSigHandler;AtpSigHCommData;rca;sci_intel_mpi;sci_intel;mpich_intel;mpichcxx_intel;stdc++;imf;m;ifcore;ifport;pthread;imf;svml;irng;stdc++;m;ipgo;decimal;cilkrts;stdc++;irc;svml;c;irc_s;dl;c
-- Configuring done
-- Generating done
-- Build files have been written to: /users/ccranor/tmp/cmake4/b
%
```
notice that "incdir:" is empty the first time you run cmake. Now if you rerun cmake, "incdir:" becomes "/usr/include!
```
% env CC=cc CXX=CC cmake ..
-- Cray Programming Environment 2.5.12 C
-- Cray Programming Environment 2.5.12 CXX
STATUS: incdir: /usr/include
STATUS: lnkdir: /opt/cray/pe/libsci/17.09.1/INTEL/16.0/x86_64/lib;/opt/cray/dmapp/default/lib64;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/lib;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/lib64;/opt/cray/pe/atp/2.1.1/libApp;/opt/intel/2017.4.196/compilers_and_libraries_2017/linux/mkl/lib/intel64;/opt/intel/2017.4.196/compilers_and_libraries_2017.4.196/linux/compiler/lib/intel64_lin;/opt/gcc/6.3.0/snos/lib/gcc/x86_64-suse-linux/6.3.0;/opt/gcc/6.3.0/snos/lib64;/lib64;/usr/lib64;/opt/gcc/6.3.0/snos/lib;/lib;/usr/lib
STATUS: lnklib: intlc;AtpSigHandler;AtpSigHCommData;rca;sci_intel_mpi;sci_intel;mpich_intel;mpichcxx_intel;stdc++;imf;m;ifcore;ifport;pthread;imf;svml;irng;stdc++;m;ipgo;decimal;cilkrts;stdc++;irc;svml;c;irc_s;dl;c
-- Configuring done
-- Generating done
-- Build files have been written to: /users/ccranor/tmp/cmake4/b
%
```
I compiled a more recent version of cmake and fixed the ${src} bug in CrayPrgEnv. Here is output from that:
```
% rm -rf *
% ~/tmp/cmake/bin/cmake --version
cmake version 3.10.0-rc3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
%
%
% env CC=cc CXX=CC ~/tmp/cmake/bin/cmake ..
-- The C compiler identification is Intel 17.0.4.20170411
-- The CXX compiler identification is Intel 17.0.4.20170411
-- Cray Programming Environment 2.5.12 C
-- Check for working C compiler: /opt/cray/pe/craype/2.5.12/bin/cc
-- Check for working C compiler: /opt/cray/pe/craype/2.5.12/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Cray Programming Environment 2.5.12 CXX
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.12/bin/CC
-- Check for working CXX compiler: /opt/cray/pe/craype/2.5.12/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
STATUS: incdir: /opt/cray/pe/libsci/17.09.1/INTEL/16.0/x86_64/include;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/include;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/include;/opt/cray/alps/6.4.1-6.0.4.0_7.2__g86d0f3d.ari/include;/opt/cray/xpmem/2.2.2-6.0.4.0_3.1__g43b0535.ari/include;/opt/cray/gni-headers/5.0.11-6.0.4.0_7.2__g7136988.ari/include;/opt/cray/pe/pmi/5.0.12/include;/opt/cray/ugni/6.0.14-6.0.4.0_14.1__ge7db4a2.ari/include;/opt/cray/udreg/2.3.2-6.0.4.0_12.2__g2f9c3ee.ari/include;/opt/cray/wlm_detect/1.2.1-6.0.4.0_22.1__gd26a3dc.ari/include;/opt/cray/krca/2.2.2-6.0.4.0_5.2__g4614cf3.ari/include;/opt/cray-hss-devel/8.0.0/include;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/include;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/include;/opt/cray/alps/6.4.1-6.0.4.0_7.2__g86d0f3d.ari/include;/opt/cray/xpmem/2.2.2-6.0.4.0_3.1__g43b0535.ari/include;/opt/cray/gni-headers/5.0.11-6.0.4.0_7.2__g7136988.ari/include;/opt/cray/pe/pmi/5.0.12/include;/opt/cray/ugni/6.0.14-6.0.4.0_14.1__ge7db4a2.ari/include;/opt/cray/udreg/2.3.2-6.0.4.0_12.2__g2f9c3ee.ari/include;/opt/cray/wlm_detect/1.2.1-6.0.4.0_22.1__gd26a3dc.ari/include;/opt/cray/krca/2.2.2-6.0.4.0_5.2__g4614cf3.ari/include;/opt/cray-hss-devel/8.0.0/include
STATUS: lnkdir: /opt/cray/pe/libsci/17.09.1/INTEL/16.0/x86_64/lib;/opt/cray/dmapp/default/lib64;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/lib;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/lib64;/opt/cray/pe/atp/2.1.1/libApp;/opt/intel/2017.4.196/compilers_and_libraries_2017/linux/mkl/lib/intel64;/opt/intel/2017.4.196/compilers_and_libraries_2017.4.196/linux/compiler/lib/intel64_lin;/opt/gcc/6.3.0/snos/lib/gcc/x86_64-suse-linux/6.3.0;/opt/gcc/6.3.0/snos/lib64;/lib64;/usr/lib64;/opt/gcc/6.3.0/snos/lib;/lib;/usr/lib
STATUS: lnklib: intlc;AtpSigHandler;AtpSigHCommData;rca;sci_intel_mpi;sci_intel;mpich_intel;mpichcxx_intel;stdc++;imf;m;ifcore;ifport;pthread;imf;svml;irng;stdc++;m;ipgo;decimal;cilkrts;stdc++;gcc;gcc_s;irc;svml;c;gcc;gcc_s;irc_s;dl;c
-- Configuring done
-- Generating done
-- Build files have been written to: /users/ccranor/tmp/cmake4/b
%
```
Now incdir: is partially correct (but doesn't include /usr/include, as I noted above).
But if I rerun "cmake" it gets reduced to "/usr/include" because the output isn't saved anywhere like CMakeCXXCompiler.cmake...
```
% env CC=cc CXX=CC ~/tmp/cmake/bin/cmake ..
-- Cray Programming Environment 2.5.12 C
-- Cray Programming Environment 2.5.12 CXX
STATUS: incdir: /usr/include
STATUS: lnkdir: /opt/cray/pe/libsci/17.09.1/INTEL/16.0/x86_64/lib;/opt/cray/dmapp/default/lib64;/opt/cray/pe/mpt/7.6.2/gni/mpich-intel/16.0/lib;/opt/cray/rca/2.2.11-6.0.4.0_13.2__g84de67a.ari/lib64;/opt/cray/pe/atp/2.1.1/libApp;/opt/intel/2017.4.196/compilers_and_libraries_2017/linux/mkl/lib/intel64;/opt/intel/2017.4.196/compilers_and_libraries_2017.4.196/linux/compiler/lib/intel64_lin;/opt/gcc/6.3.0/snos/lib/gcc/x86_64-suse-linux/6.3.0;/opt/gcc/6.3.0/snos/lib64;/lib64;/usr/lib64;/opt/gcc/6.3.0/snos/lib;/lib;/usr/lib
STATUS: lnklib: intlc;AtpSigHandler;AtpSigHCommData;rca;sci_intel_mpi;sci_intel;mpich_intel;mpichcxx_intel;stdc++;imf;m;ifcore;ifport;pthread;imf;svml;irng;stdc++;m;ipgo;decimal;cilkrts;stdc++;gcc;gcc_s;irc;svml;c;gcc;gcc_s;irc_s;dl;c
-- Configuring done
-- Generating done
-- Build files have been written to: /users/ccranor/tmp/cmake4/b
%
```Chuck AtkinsChuck Atkinshttps://gitlab.kitware.com/cmake/cmake/-/issues/17410Ctest exclude regex2017-10-30T10:33:10-04:00Jonathan WCtest exclude regexUnfortunately the ctest exclude regex (and also those for -R) do not seem to work as I would expect it.
I have tests like
```
test_geometry_pass
test_mesh
integration_test_render
project--cpplint
...
```
I would like to have a target t...Unfortunately the ctest exclude regex (and also those for -R) do not seem to work as I would expect it.
I have tests like
```
test_geometry_pass
test_mesh
integration_test_render
project--cpplint
...
```
I would like to have a target to e.g. only run the unit tests, so not integration tests and not cpplint, for which I guarantee that the names always start with ``test``
So I thought to create a target in CMake like:
```
add_custom_target(Unit-Test-Suite COMMAND ctest -R "^test" -C $<CONFIG>)
```
Unfortunately that also triggers ``integration_test_render`` since the start regex-symbol seems to be ignored. I also tried something like:
```
ctest -E "(integration_test)|(cpplint)"
```
which cmake did not like, since the | seemed to be interpreted differently.
Is this a bug or is this not the common regex expression as described in the [string doku](https://cmake.org/cmake/help/v3.0/command/string.html)https://gitlab.kitware.com/cmake/cmake/-/issues/17408CUDA as a language issues2018-04-24T13:47:49-04:00Henry SchreinerCUDA as a language issuesI've been taking a significant package over to optionally using CUDA as a language in CMake 3.8+ (Windows support is not available for the package). When doing so, I ran into several issues. Here's a description of the process, then the ...I've been taking a significant package over to optionally using CUDA as a language in CMake 3.8+ (Windows support is not available for the package). When doing so, I ran into several issues. Here's a description of the process, then the issues.
To make the two procedures similar enough to support concurrently, I copied the FindCUDA module from CMake 3.9 into a git repository and changed the pair of absolute links to relative ones. Then, in my package, I optionally include the git submodule if CMake < 3.8. (It should work back as far as 3.6 or 3.4, maybe even further.) The reason I absolutely had to have 3.9 version? The ability to use `PRIVATE`/`PUBLIC`/`INTERFACE`! I converted away from using global includes/etc anywhere, except for `CXX_STANDARD` settings.
Then, I set up the new CUDA language. This is where the issues came up. Of course, it's already known, but the FindCUDA package is still needed to see if CUDA is available. (Edit: the VERSION of CUDA is available at `CMAKE_CUDA_COMPILER_VERSION`), and to get the arch selection. The arch selection script should be modified to use the new language support (it almost is stand-alone), and then it could be wrapped with something like this:
```cmake
function(CUDA_DETECT_ARCH)
set(oneValueArgs NVCC_FLAGS READABLE)
cmake_parse_arguments(
CDA
""
"${oneValueArgs}"
""
${ARGN})
cuda_select_nvcc_arch_flags(CDA_val)
if(NOT CDA_FLAGS STREQUAL "")
string(REPLACE ";" " " CDA_flags_val "${CDA_val}")
set(${CDA_NVCC_FLAGS} "${CDA_flags_val}" PARENT_SCOPE)
endif()
if(NOT CDA_READABLE STREQUAL "")
set(${CDA_READABLE} "${CDA_val_readable}" PARENT_SCOPE)
endif()
endfunction()
```
That way, it would still be easy to maintain CUDA ARCH names and versions in one place. This also fixes the output of `cuda_select_nvcc_arch_flags` for CUDA as a language.
Second, unlike the older method, CUDA as a language has an awful time understanding compiler flags. If, for example, you have a flag on an INTERFACE target, it does not get wrapped with `-Xcompiler`. A possible solution, and the one that was suggested at [GTC 2017](http://on-demand.gputechconf.com/gtc/2017/presentation/S7438-robert-maynard-build-systems-combining-cuda-and-machine-learning.pdf), was to use the `COMPILE_LANGUAGE` generator expression. Which, according to [the docs](https://cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html), does not work on Windows (Is it still impossible to fix that?).
Even when using this, most libraries, including most of the find_modules, are not set up for this. So, I use the following pair of macros to "fix" the targets for CUDA:
```cmake
function(CUDA_CONVERT_FLAGS EXISTING_TARGET)
get_property(old_flags TARGET ${EXISTING_TARGET} PROPERTY INTERFACE_COMPILE_OPTIONS)
if(NOT "${old_flags}" STREQUAL "")
string(REPLACE ";" "," CUDA_flags "${old_flags}")
set_property(TARGET ${EXISTING_TARGET} PROPERTY INTERFACE_COMPILE_OPTIONS
"$<$<BUILD_INTERFACE:$<COMPILE_LANGUAGE:CXX>>:${old_flags}>$<$<BUILD_INTERFACE:$<COMPILE_LANGUAGE:CUDA>>:-Xcompiler=${CUDA_flags}>"
)
endif()
endfunction()
function(CUDA_PROTECT_FLAGS EXISTING_TARGET)
get_property(old_flags TARGET ${EXISTING_TARGET} PROPERTY INTERFACE_COMPILE_OPTIONS)
if(NOT "${old_flags}" STREQUAL "")
set_property(TARGET ${EXISTING_TARGET} PROPERTY INTERFACE_COMPILE_OPTIONS
"$<$<BUILD_INTERFACE:$<COMPILE_LANGUAGE:CXX>>:${old_flags}>"
)
endif()
endfunction()
```
But, this has a problem: if the target is an ALIAS target, it won't work. Is there a way to resolve an ALIAS target?
# Wishlist for CUDA.cmake
* [x] CUDA detection
* [x] CUDA ARCH detection script modified to support either form of CUDA
* [ ] CUDA ARCH detection wrapper with better output for CUDA language
* [x] Windows compatibale target solution
* [ ] CONVERT/PROTECT flags solution
* [ ] Working on ALIAS (and IMPORTED?) targets
I've started an initial version of CUDA.cmake [here](https://github.com/CLIUtils/cmake/blob/master/CUDA.cmake). If you'd like to see the library's CMake, it's [here](https://github.com/GooFit/GooFit/blob/master/CMakeLists.txt). I haven't tackled fixing some the edge cases yet, like the MPI target with CUDA.https://gitlab.kitware.com/cmake/cmake/-/issues/17407CompilerCache find/use module2017-10-30T11:55:59-04:00Henry SchreinerCompilerCache find/use moduleThis is work based on https://crascit.com/2016/04/09/using-ccache-with-cmake. The is a fair about of setup to get CCache and similar tools to work in a CMake build environment, especially with newer versions of GCC/Clang mixed with older...This is work based on https://crascit.com/2016/04/09/using-ccache-with-cmake. The is a fair about of setup to get CCache and similar tools to work in a CMake build environment, especially with newer versions of GCC/Clang mixed with older versions of CCache, or with Xcode.
The first step in an upstream solution will be to teach Xcode the
about the `CMAKE_<LANG>_COMPILER_LAUNCHER` variable.
For the current external solution:
While the solution is fairly simple, there are several choices for design:
1. An `include(CompilerCache)` file that automatically setups up compiler caches. This works great for most use cases, but is not flexible. An example of that is at https://github.com/CLIUtils/cmake/blob/master/CCache.cmake
2. An `include(CompilerCache)` file that provides a function that setups up compiler caches. This is the most flexible and can support different programs or different paths. An early version, incomplet and inkorrect, is available at https://gitlab.kitware.com/henryiii/cmake/blob/cache/Modules/UseCompilerCache.cmake.
3. A `find_program(CompilerCache)` that finds CCache then provides a function like seen above. Might be a similarly good solution. I'm happy to convert to that if desired. However, might be a little harder to be flexible for things like ClCache.
https://gitlab.kitware.com/cmake/cmake/-/issues/17405FindCurses doesn't pull correct linker flags2019-09-23T11:47:25-04:00Kirill BobyrevFindCurses doesn't pull correct linker flagsWhen trying to link NCruses via CMake
A minimal example to reproduce on my system:
CMakeLists.txt
```CMake
cmake_minimum_required(VERSION 3.9)
project(main)
find_package(Curses REQUIRED)
include_directories(${CURSES_INCLUDE_DIR})
add...When trying to link NCruses via CMake
A minimal example to reproduce on my system:
CMakeLists.txt
```CMake
cmake_minimum_required(VERSION 3.9)
project(main)
find_package(Curses REQUIRED)
include_directories(${CURSES_INCLUDE_DIR})
add_executable(main main.cpp)
target_link_libraries(main ${CURSES_LIBRARIES})
```
main.cpp
```c++
#include <ncurses.h>
int main() {
initscr(); /* Start curses mode */
printw("Hello World !!!"); /* Print Hello World */
refresh(); /* Print it on to the real screen */
getch(); /* Wait for user input */
endwin(); /* End curses mode */
return 0;
}
```
```bash
[omtcyfz@omtcyfz-arch build]$ ninja -v
[1/1] : && /usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main -lcurses -lform && :
FAILED: main
: && /usr/bin/c++ CMakeFiles/main.dir/main.cpp.o -o main -lcurses -lform && :
/usr/bin/ld: CMakeFiles/main.dir/main.cpp.o: undefined reference to symbol 'stdscr'
/usr/lib/libtinfo.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
```
Affected NCurses version: [6.0+20170902-2](https://www.archlinux.org/packages/core/i686/ncurses/) installed from Arch core packages. CMake version: 3.9.4-1.
I recently submitted a [bug](https://bugs.archlinux.org/task/56137?project=1&cat%5B0%5D=31&string=ncurses) for Arch Linux ncurses package and the response was:
> Most likely you'll need -ltinfo as well. Arch's ncurses is split into libncurses+libtino+libtic since 6.0+20170902-2
As far as my understanding goes, the "correct" way of handling it would be asking pkg-config, which is the default build system for NCurses, for the correct linker flags instead of hardcoding them.
[Here](https://bugs.archlinux.org/task/56000)'s one more related discussion.