On Nov 19, 2007 2:39 PM, Stephen Collyer <[EMAIL PROTECTED]> wrote: > > FIND_PATH(CURL_INCLUDE_DIR NAMES curl/curl.h) > > i.e. it hard-codes the assumption that curl.h lives in > a directory called curl. In my case, it doesn't: it lives > in a directory called include and no amount of adding to > or subtracting from the default directories that FIND_PATH > search from will fix this problem.
Is #include "curl/curl.h" the expected way that the library header is supposed to be used? If so, then CMake is doing the correct thing. There are plenty of libraries out there that require directory prefixes, like "GL/gl.h" for OpenGL, or many of the X11 libraries. If that is true for curl, then you should install your header as curl/curl.h in some directory somewhere. > However, that's not efficient; if a thousand people download > the same curl development package, a thousand people have to > repeat the same hard-coding trick to build my tree. If curl/curl.h is the standard convention, and you choose not to do it that way, then your choice of layout is inefficient. Other curl users won't be troubled. If, on the other hand, curl really is installed in "curl.h" and "curl/curl.h" form on various systems, then I agree that CMake should not hardwire the directory. So which is it? Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
