[CMake] Add search paths for FIND_PACKAGE ?

[Stephen Collyer]

Andreas Pakulat wrote:
> On 19.11.07 19:39:45, Stephen Collyer wrote:

>> I guess that solves the problem, but it seems like a hack,
>> rather than a solution. It seems to me that the problem
>> is that FindCURL.make does this:
>>
>> 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. Hence your hack: tell
>> cmake explicitly where to look and all is well.
> 
> Usually this indicates a lack of cross-platform tests for the library in
> question. You should open a bugreport with Kitware to get this fixed.
> Unless of course you're not using the official sources or official
> binaries for Curl (or hacked the sources for the install location you
> got)

As far as I'm aware, there are no "official" curl binaries or devel
packages, and if you don't want to build from source (I don't
particularly) you have to download one of the prebuilt development
packages advertised on http://curl.haxx.se/download.html - these
are provided by third parties.

I downloaded the 7.15.1 MSVC version with SSL support (there's only
one) from
http://my.guardpuppy.com/libcurl-7.15.1-msvc-win32-ssl-0.9.8a-zlib-1.2.3.zip
and it provides the directory structure that I described earlier.

Now, as to whether this indicates a lack of cross-platform tests,
I'm not sure. On my SuSe installation, curl.h has been packaged to
end up in /usr/include/curl/curl.h which matches the current
FindCURL.cmake. All of the Windows development packages seem to
have this extra include, though. Strangely enough, there's no
include dir in the source tree, so maybe it's a convention that
the package builders have adopted.

Is this worth raising as a bug ?

-- 
Regards

Steve Collyer
Netspinner Ltd