>> I fixed it in GIT hash 899586d. For reference, the >> inotify.h file can >> commonly exist in one of two places; the check that is in >> tdelibs (and now >> in Amarok) looks both places before giving up. > > Great. :) > > I think that needs to be done with most packages. For example, many only > look in /usr/include and not any subdirectories. With the little I have > browsed cmake files, I think cmake can be configured for that. I don't > know about automake. Not finding header files in a subdirectory seems to > be a common building bug. Automake has the --with-extra-includes option, > but find header files should be automatic. Likewise with cmake. :) > > Darrell 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. Tim