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