View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014648 | CMake | (No Category) | public | 2013-12-15 08:32 | 2016-06-10 14:31 | ||||
Reporter | Robert·Luberda | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | high | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake 2.8.12 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0014648: Need an option to skip system headers while generating dependencies | ||||||||
Description | There is currently no way to tell cmake not to consider system headers while generating dependencies. If the source file contain for example the following includes: #include <iostream> #include <boost/lexical_cast.hpp> #include <tbb/atomic.hpp> #include <unistd.h> #include <sys/types.h> #include "projectdir1/header1.h" #include "projectdir2/header2.hpp" #include "header3.h" then CMake will try to find each of the file in the directories given by include_directories(), which has a *huge* performance impact on build process when CMake happens to actually find the files (please note that CMake does not consider some system dirs like /usr/include or /usr/include/c++/4.8 by default, and that's why the issue is somehow hidden. BTW. This is a really strange - why e.g. boost header from /usr/include are treated differently than those ones from /opt/boost-1.55.0/include?). However the system header files do not change often, and can be ignored by CMake in a two ways: - by ignoring the files that are #included inside the < > brackets - by ignoring directories that are marked as SYSTEM ones during scanning for files (it could by some new property like NOT-FOR-DEPS instead of SYSTEM), just like `g++ -MM' does (and you know, g++ provides such an option for a reason...) I assume there might be some projects that require dependencies for system headers, so that features need to be configurable. And yes, in my opinion it would be nice to have both of the features implemented, it really shouldn't be a rocket science. The currently provided features does not fix the issue: - include_regular_expression() is not a solution, as it's hardly possible to enumerate all non-system headers with it; - the `fast' targets are not an option either, as they ignore all the dependencies, besides there is no `all/fast' target (see also https://blogs.kde.org/2006/08/06/working-cmake-dependency-hell [^]) - there is INCLUDE_REGEX_LINE variable in CMake sources, but it seems to be hardcoded, cannot be changed by user. | ||||||||
Steps To Reproduce | Take any really big C++ project using boost (and other libraries) from non-standard locations (or make sure the boost headers are visible to cmake, but using something like `include_directiories("/usr/include")') and watch the poor performance... | ||||||||
Additional Information | There are already two quite an old bugs about same issues: http://public.kitware.com/Bug/view.php?id=2607 [^] http://public.kitware.com/Bug/view.php?id=8777 [^] | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Relationships |
Notes | |
(0034775) Marcel Loose (developer) 2013-12-16 03:02 |
The C/C++ standard does not require that system headers are #included inside < > brackets. Nor does the C standard forbid to #include user-defined header files inside < > brackets. So the first option for ignoring header files cannot be used. |
(0034776) Robert·Luberda (reporter) 2013-12-16 03:30 |
Nothing in C/C++ standard prevents people from setting up theirs own coding standards, that require system headers inside < >, and project headers being inside " ". We have such a requirement in our project, and - believe or not - people do obey it. So yes, this option can be used, but only when a user explicitly enables it. |
(0042448) 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. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2013-12-15 08:32 | Robert·Luberda | New Issue | |
2013-12-16 03:02 | Marcel Loose | Note Added: 0034775 | |
2013-12-16 03:30 | Robert·Luberda | Note Added: 0034776 | |
2013-12-18 11:07 | Brad King | Relationship added | related to 0014650 |
2016-06-10 14:29 | Kitware Robot | Note Added: 0042448 | |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |