MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015458CMakeCMakepublic2015-03-18 18:322016-06-10 14:31
ReporterAxel Huebl 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformallOSOS Version
Product VersionCMake 3.2.1 
Target VersionFixed in Version 
Summary0015458: Expose SYSTEM INCLUDE_DIRECTORIES to CMake code
DescriptionAs documented in a feature request in
  http://www.cmake.org/Bug/view.php?id=14415 [^]

there is currently no functionality available to restore attributes such as "is marked as a system path" from directories, e.g., for calls to
  get_directory_property(INCLUDE_DIRECTORIES)

Being able to read such information again would be beneficial, e.g., for modules such as FindCUDA that have to forward the include directories to a wrapped compiler or similar.

Right now, that is not possible, causing very noisy output for warnings caused by header files - and users of these libraries have no chance to mute them accordingly.
Steps To ReproduceFor an example, see the RFE in FindCUDA
  http://www.cmake.org/Bug/view.php?id=14415 [^]
Additional Information
TagsNo tags attached.
Relationships
related to 0014415closed James Bigler FindCUDA.cmake INCLUDE_DIRECTORIES add/honor optional SYSTEM flag 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-03-18 18:32Axel HueblNew Issue
2015-04-14 07:19bchretienNote Added: 0038506
2015-04-14 08:24Brad KingRelationship addedrelated to 0014415
2015-04-14 08:28Brad KingNote Added: 0038507
2015-04-14 08:30Brad KingNote Added: 0038508
2015-04-14 10:15Brad KingSummaryNew Functionality to Restore Directory Attributes => Expose SYSTEM INCLUDE_DIRECTORIES to CMake code
2015-04-14 10:20Brad KingNote Added: 0038509
2015-04-14 10:24Brad KingNote Added: 0038510
2015-04-14 10:27Brad KingNote Added: 0038511
2016-06-10 14:29Kitware RobotNote Added: 0042736
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0038506)
bchretien   
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   
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   
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   
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   
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   
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   
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.