(0038506)
bchretien (reporter)
2015-04-14 07:19

Not being able to filter these warnings is quite troublesome indeed (I just had to go through tens of MB of useless warnings coming from CUDA generated files that also ended up being treated with -I). I'm not familiar with the C++ part of CMake's implementation, but the information we need appears to be available in a std::set<std::string>, so could this "simply" be solved by adding an extra property? (e.g. SYSTEM_INCLUDE_DIRECTORIES, although INCLUDE_DIRECTORIES would still contain these include directories)

(0038507)
Brad King (manager)
2015-04-14 08:28

Related mailing list thread:

Patch: FindCUDA.cmake -Wall Warnings
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12840/focus=12846 [^]

See note about use of isystem causing compilation to break.

(0038508)
Brad King (manager)
2015-04-14 08:30

Another slightly related mailing list thread:

CUDA as a compiler instead FindCUDA?
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12128 [^]

(0038509)
Brad King (manager)
2015-04-14 10:20

For reference, the INCLUDE_DIRECTORIES directory property implementations for setting, appending, and getting are here:

http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4099 [^]
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4158 [^]
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4277 [^]

(0038510)
Brad King (manager)
2015-04-14 10:24

For pure C and C++ projects, the use of directory-level include_directories() has been superseded by target_include_directories() along with usage requirement propagation through target_link_libraries. That all supports per-target SYSTEM include directory marks.

FindCUDA reads the INCLUDE_DIRECTORIES property, but that may now have generator expressions that cannot be evaluated during configuration and must be delayed until generation time. Furthermore, FindCUDA may one day have to try to honor target_include_directories invocations on the targets it creates. Both of these would require delaying generation of the compilation command line until generate time. This could possibly be achieved using file(GENERATE) and a level of indirection at build time. Otherwise CUDA will have to be implemented as a first-class language on the C++ side of CMake's implementation.

(0038511)
Brad King (manager)
2015-04-14 10:27

Re 0015458:0038510:

> Otherwise CUDA will have to be implemented as a first-class language

Without that, FindCUDA can only do so much to act as much like a first-class language as possible. Rather than trying to do so, perhaps FindCUDA should instead offer its own APIs to specify include directories, system include directories, and other build system information. Then it won't need any special support for reading properties normally used by the C++-implemented generators.

(0042736)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2015-03-18 18:32	Axel Huebl	New Issue
2015-04-14 07:19	bchretien	Note Added: 0038506
2015-04-14 08:24	Brad King	Relationship added	related to 0014415
2015-04-14 08:28	Brad King	Note Added: 0038507
2015-04-14 08:30	Brad King	Note Added: 0038508
2015-04-14 10:15	Brad King	Summary	New Functionality to Restore Directory Attributes => Expose SYSTEM INCLUDE_DIRECTORIES to CMake code
2015-04-14 10:20	Brad King	Note Added: 0038509
2015-04-14 10:24	Brad King	Note Added: 0038510
2015-04-14 10:27	Brad King	Note Added: 0038511
2016-06-10 14:29	Kitware Robot	Note Added: 0042736
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0038506) bchretien (reporter) 2015-04-14 07:19	Not being able to filter these warnings is quite troublesome indeed (I just had to go through tens of MB of useless warnings coming from CUDA generated files that also ended up being treated with -I). I'm not familiar with the C++ part of CMake's implementation, but the information we need appears to be available in a std::set<std::string>, so could this "simply" be solved by adding an extra property? (e.g. SYSTEM_INCLUDE_DIRECTORIES, although INCLUDE_DIRECTORIES would still contain these include directories)

(0038507) Brad King (manager) 2015-04-14 08:28	Related mailing list thread: Patch: FindCUDA.cmake -Wall Warnings http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12840/focus=12846 [^] See note about use of isystem causing compilation to break.

(0038508) Brad King (manager) 2015-04-14 08:30	Another slightly related mailing list thread: CUDA as a compiler instead FindCUDA? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12128 [^]

(0038509) Brad King (manager) 2015-04-14 10:20	For reference, the INCLUDE_DIRECTORIES directory property implementations for setting, appending, and getting are here: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4099 [^] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4158 [^] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmMakefile.cxx;hb=v3.2.1#l4277 [^]

(0038510) Brad King (manager) 2015-04-14 10:24	For pure C and C++ projects, the use of directory-level include_directories() has been superseded by target_include_directories() along with usage requirement propagation through target_link_libraries. That all supports per-target SYSTEM include directory marks. FindCUDA reads the INCLUDE_DIRECTORIES property, but that may now have generator expressions that cannot be evaluated during configuration and must be delayed until generation time. Furthermore, FindCUDA may one day have to try to honor target_include_directories invocations on the targets it creates. Both of these would require delaying generation of the compilation command line until generate time. This could possibly be achieved using file(GENERATE) and a level of indirection at build time. Otherwise CUDA will have to be implemented as a first-class language on the C++ side of CMake's implementation.

(0038511) Brad King (manager) 2015-04-14 10:27	Re 0015458:0038510: > Otherwise CUDA will have to be implemented as a first-class language Without that, FindCUDA can only do so much to act as much like a first-class language as possible. Rather than trying to do so, perhaps FindCUDA should instead offer its own APIs to specify include directories, system include directories, and other build system information. Then it won't need any special support for reading properties normally used by the C++-implemented generators.

(0042736) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.