Bug 137644

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.