>> 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