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