Version: 3.3.93 (using KDE KDE 3.5.5) Installed from: SuSE RPMs OS: Linux This relates to http://bugs.kde.org/show_bug.cgi?id=106379. The problem to be addressed is that the files processed by the PCS when specified by directory and file extension filters are not always the ones that the user wants or expects to be processed. There are at least the following two cases in which this happens. When the files don't have file name extensions. When there are files that match the filter, but don't belong in the db. The at some point in the process, the PCS simply iterates over a list of file names. It should therefore be relatively easy to insert an alternative means of providing that list. I propose adding an option to provide a file name explicitly. In this case the file is intended to be parsed as source code. That solves two problems: It supports the use of file names without extensions. It it provides a means of omitting inappropriate files. It would, however be a a bit tedious in cases such as OSG where there are hundreds of files to be processed. One means of addressing that situation would be to add a facility for specifying a file containing a list of files to be processed. A reasonable format for such a file would be standard CPP. For example: #ifndef STD_HEADERS_H #define STD_HEADERS_H #include <algorithm> #include <bitset> #include <cctype> #include <cfloat> #include <climits> #include <cmath> #include <complex> #include <cstddef> #include <cstdlib> #include <cstring> #include <ctime> #include <deque> #include <exception> #include <fstream> #include <functional> #include <iomanip> #include <ios> #include <iosfwd> #include <iostream> #include <istream> #include <iterator> #include <limits> #include <list> #include <locale> #include <map> #include <memory> #include <new> #include <numeric> #include <ostream> #include <queue> #include <set> #include <sstream> #include <stack> #include <stdexcept> #include <streambuf> #include <string> #include <typeinfo> #include <utility> #include <valarray> #include <vector> #endif As a first cut, the file could be processed relative to the directory where it lives. A better, albeit, more difficult method would be to search the include path in the same way the CPP does to resolve #includes. I will also propose the use of #pragma rpp_recursive \n #pragma rpp_end_recursive to tell the rpp to follow the #includes in a given file. It could even take a depth argument to tell it how many levels of #include it should follow.
I don't quite understand the problem. To parse std-c++ you I just put * into the file-pattern-field and it works just fine! And Imo the code-completion already now needs too much user-interaction(creating the repositories), writing such a file would be too much. I think the best solution for really hard cases would be just parsing included headers that are covered by no repository automatically, all requirements for that are fulfilled, but I think the feature-freeze won't allow that.
wont change in kdev3 and no pcs databases in kdev4.