MantisBT - CMake
View Issue Details
0002607CMakeCMakepublic2005-12-14 05:032016-06-10 14:30
Gregor Berginc 
Brad King 
lowfeaturealways
closedmoved 
 
 
0002607: Ignoring certain paths during dependency scanning
If you use, for example, the `g++ -MM' command to scan for c++ dependencies, the g++ ignores include files, found in system paths, which are given in a system variable CPLUS_INCLUDE_PATH.

It would be great if we could use a similar command to add paths that would be ignored by the cmake.
No tags attached.
Issue History
2012-08-13 10:36Brad KingStatusassigned => backlog
2012-08-13 10:36Brad KingNote Added: 0030518
2016-06-10 14:27Kitware RobotNote Added: 0041304
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0004768)
Alex Neundorf   
2006-08-27 10:59   
Maybe this would also help against the performance issues Thomas Zander has when compiling e.g. kdeui/ and it starts recompiling kdecore/ although he didn't want that ?
(0004790)
Brad King   
2006-08-29 09:17   
This report talks about the other direction. Changing headers in kdecore should cause kdeui to rebuild, and it does. Thomas is complaining about changing kdeui and suddenly kdecore starts to rebuild...that is a separate issue. The reporter of this bug requests a directory version of INCLUDE_REGULAR_EXPRESSION.
(0004795)
Alex Neundorf   
2006-08-29 12:35   
No, I don't think so.
As KDE developer you usually update a complete module from svn, e.g. kdelibs/ which contain among other kdecore/ and kdeui/.
So he complains that he only wants to work in kdeui/, but after updating from svn and trying to build kdeui/ make starts to build kdecore/ because stuff there has changed too and kdeui/ depends on kdecore/.

(0004796)
Brad King   
2006-08-29 12:56   
The dependency of kdeui on kdecore is target-level and has nothing to do with dependency scanning of include files. This is not the same bug. You want bug 0003658 which is totally different.
(0030518)
Brad King   
2012-08-13 10:36   
Sending issues I'm not actively working on to the backlog to await someone with time for them.

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it:

 http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer or contributor who has the bandwidth to take it on.
(0041304)
Kitware Robot   
2016-06-10 14:27   
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.