MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011985CMakeCMakepublic2011-03-18 10:132016-06-10 14:31
ReporterMathias Gaunard 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformAnyOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0011985: CMake scanner doesn't extract dependencies of C and C++ files correctly
DescriptionDue to using a simplified scanner that doesn't do full preprocessing, include directives that depend on C/C++ preprocessor usage are not dealt with correctly.

This has been discussed on the mailing list here:
http://www.cmake.org/pipermail/cmake/2010-July/038465.html [^]

CMake should detect when files contain non-trivial include directives and invoke a full C preprocessor in that case.

Alternatively CMake could provide a way to override the tool used to detect those dependencies.
Indeed, in the current situation, there seems to be no workaround possible. Explicitly adding OBJECT_DEPENDS properties doesn't seem to work either.
Steps To ReproduceDownload attached testcase.
Run cmake with the Makefile or NMakefile generator.
Make the 'test' target.
Touch test2.hpp to make it more recent
Make the 'test' target again, and notice nothing gets recompiled
Additional InformationHaving correct dependencies of C/C++ files is extremely important, especially for continuous integration solutions.

Such includes exist in various libraries. The Boost C++ libraries contain such includes to generate its meta-programming code, while several other libraries use such includes to conditionally include code for one architecture or another.
TagsNo tags attached.
Relationships
related to 0013718closed Kitware Robot CMake does not preprocess out conditional includes while scanning dependencies 
Attached Filesbz2 test_cmake.tar.bz2 (431) 2011-03-18 10:13
https://public.kitware.com/Bug/file/3758/test_cmake.tar.bz2
Issue History
Date ModifiedUsernameFieldChange
2011-03-18 10:13Mathias GaunardNew Issue
2011-03-18 10:13Mathias GaunardFile Added: test_cmake.tar.bz2
2011-03-18 10:18Mathias GaunardNote Added: 0025805
2011-03-18 10:33Michael WildNote Added: 0025806
2011-03-19 09:19Mathias GaunardNote Added: 0025828
2011-03-19 11:09Michael WildNote Added: 0025833
2011-03-29 18:02Brad KingStatusnew => backlog
2012-11-20 09:27Brad KingRelationship addedrelated to 0013718
2012-11-20 10:43Mathias GaunardNote Added: 0031624
2013-01-05 03:00Peter KuemmelSummaryCMake scanner does extract dependencies of C and C++ files correctly => CMake scanner doesn't extract dependencies of C and C++ files correctly
2016-06-10 14:28Kitware RobotNote Added: 0041822
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0025805)
Mathias Gaunard   
2011-03-18 10:18   
Sorry, should be "CMake scanner doesn't extract dependencies of C and C++ files correctly".
Can't find how to update the summary.
(0025806)
Michael Wild   
2011-03-18 10:33   
Just a crazy idea, but couldn't CMake use the clang libraries (libbasic and liblex should do the trick AFAIK) to do actual, correct preprocessing? The clang license is a BSD-variant, and should be compatible with the one used by CMake, so the sources could actually be included in CMake...
(0025828)
Mathias Gaunard   
2011-03-19 09:19   
Beware with using the clang libraries.
To have the correct dependencies, the preprocessor would need to behave exactly like the target compiler: have all the same macros predefined, and more importantly exhibit the same preprocessing bugs.
(0025833)
Michael Wild   
2011-03-19 11:09   
True. Didn't think of that. There are two other options I can see which don't suffer from above mentioned problems:

- Ask the compiler to come up with a list of dependencies (e.g. "gcc -M"). This is problematic at best for some tool chains (e.g. requires quite some work with MS compilers), sometimes it's also unbelievably slow.

- Use LD_PRELOAD/DLL-injection to track all files opened by the compiler during compilation (take a look at Tup for an example). While potentially very complete (also handles other files, such as compiler configuration files, libraries etc.) it makes my skin crawl...
(0031624)
Mathias Gaunard   
2012-11-20 10:43   
The Ninja generator uses gcc -M for gcc and a special tool for MSVC, and is therefore not affected by this bug.
Other generators could be changed to behave like the Ninja generator.
(0041822)
Kitware Robot   
2016-06-10 14:28   
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.