10 Jan
2012
10 Jan
'12
8:30 p.m.
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