on 11/02/2012 15:14 Philip Lowman said the following: > On Thu, Feb 9, 2012 at 8:57 AM, Brad King <brad.k...@kitware.com> wrote: >>> To summarize, if the C code actually includes alsa/asoundlib.h, then >>> wouldn't it >>> be appropriate to use exactly the same path, alsa/asoundlib.h, with >>> find_path >>> like this: >>> find_path(ALSA_INCLUDE_DIR NAMES alsa/asoundlib.h >>> DOC "The ALSA (asound) include directory" >>> ) >> >> I think so. Philip? > > When I wrote that code the alsa project had somewhat recently started > putting it's 'asoundlib.h' header files in <PREFIX>/include/alsa, but > earlier releases had them in <PREFIX>/include directly. So the > PATH_SUFFIXES was put there for compatibility reasons. > > I apologize for not adding a comment for this in the module. Is the > PATH_SUFFIXES causing any problems? Is there any reason we should > convert to "NAMES alsa/asoundlib.h asoundlib.h"? > > I'll add a comment regardless of what we end up doing, but I don't see > the behavior as a bug. If the user has either > /usr/local/include/asoundlib.h OR /usr/local/include/alsa/asoundlib.h, > CMake will find /usr/local/include for the path.
Umm, as I've written in the original message, when asoundlib.h is /usr/local/include/alsa/asoundlib.h, then the current code determines include path as /usr/local/include/alsa. And that's exactly the problem. > Here is something on their wiki showing a make install output: > http://www.alsa-project.org/alsa-doc/alsa-lib/files.html > Here is somebodies autoconf script where they check for an alsa header > in include & include/alsa: > http://marchdown.xenoethics.org/src/emacs/configure.in > -- Andriy Gapon -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
