> From my perspective yes, we should search *standard* and
> project specific
> include directories.  Normally that includes
> /usr/include and
> /usr/include/<archname>, as well as
> /opt/trinity/include.  We should NOT
> search all possible custom include directories.  If
> someone installs
> something to, for example, /my/custom/includes they will
> need to specify
> the path to that directory in their CMake build flags.
> 
> In the case of inotify things are messy because there are
> actually two
> standard include directories possible--one for an (older?)
> standalone
> inotify version and one for the glibc integrated version.

I've known about both, but I never understood the difference between the two header files. Or which one is preferred. Or why. :)

I searched my local GIT tree for "linux/inotify.h" and found the following files:

main/applications/wlassistant/ConfigureChecks.cmake
main/applications/kio-locate/ConfigureChecks.cmake
main/applications/amarok/config.h.in
main/applications/amarok/amarok/configure.in.in
main/applications/amarok/amarok/src/collectiondb.cpp
main/applications/amarok/configure.in
main/applications/amarok/ConfigureChecks.cmake
main/applications/kbfx/ConfigureChecks.cmake
main/applications/kgtk-qt3/ConfigureChecks.cmake
main/applications/tde-style-qtcurve/ConfigureChecks.cmake
main/applications/rosegarden/ConfigureChecks.cmake
main/applications/tdesvn/src/svnqt/ConfigureChecks.cmake
main/applications/tdesvn/ConfigureChecks.cmake
main/applications/abakus/ConfigureChecks.cmake
main/tdepim/kmail/configure.in.in
main/tdelibs/kio/kio/configure.in.in

Looks like main/applications/amarok/amarok/src/collectiondb.cpp is hard-coded.

Darrell