[CMake] Confusion on how find_package works.

[Robert Dailey]

On Wed, Jan 14, 2009 at 9:51 PM, Robert Dailey <rcdailey at gmail.com> wrote:

>
>
> On Wed, Jan 14, 2009 at 4:20 PM, Miguel A. Figueroa-Villanueva <
> miguelf at ieee.org> wrote:
>
>> On Wed, Jan 14, 2009 at 5:54 PM, Andreas Pakulat wrote:
>> > On 14.01.09 15:45:53, Robert Dailey wrote:
>> >> On Wed, Jan 14, 2009 at 1:20 PM, Andreas Pakulat wrote:
>> >>
>> >> > If you look at the cmake docs, then you'll find out that nothing in
>> there
>> >> > states that wildcards are allowed. Hence I'd assume that wildcards
>> are not
>> >> > supported.
>> >> >
>> >> > Also you only need to set one of the two for find_path to use the
>> >> > directory.
>> >>
>> >> Well if only the CMake documentation was that reliable. There's
>> information
>> >> that I have found to be inaccurate or missing from the docs.
>> >
>> > So far I haven't found inaccurate information myself, missing yes
>> > sometimes.
>> >
>> >> For example, the documentation for find_package() no where mentions the
>> >> variable created for the COMPONENTS parameter. Looking at
>> FindBoost.cmake,
>> >> it appears to be in the form of <prefix>_FIND_COMPONENTS. Is this
>> correct?
>> >
>> > Apparently yes, but no idea where I got that from :) Would be good to
>> > file a bugreport at www.cmake.org as this is indeed missing in the
>> docs.
>>
>> Well, you can find it in the Modules/readme.txt file. However, the
>> module user doesn't need to know about the <prefix>_FIND_COMPONENTS
>> variable. This is for the FindXXX module developer. Also, note that
>> maybe you find inconsistent the information in the find_package
>> documentation, because of old or poorly written find modules that do
>> not work as they should. However, the documentation for CMake in
>> general is very reliable (although sometimes missing some).
>>
>> In your case, it seems you need to generate the list of paths to be
>> searched appropriately (no wildcard) and then use something like this:
>>
>> find_path(<VAR> NAMES name PATHS ${path_list} NO_DEFAULT_PATH)
>>
>> That is, if you don't want to search in the standard directories. Make
>> sure you appropriately handle spaces in directory names and print the
>> generated list of paths to see where you are searching.
>
>
> What do you mean by "print the generated list of paths to see where you are
> searching"? Do you mean to print ${path_list}? If not, could you explain?
>
> You are right that there are inconsistencies in the Find modules, which is
> a primary source of confusion for me. A lot of the find modules that I write
> use libfind_process(), but a lot of things store found libraries in
> inconsistent variables. For example, some Find modules place libraries in
> <prefix>_LIBRARIES, and a few place them in <prefix>_LIBRARY (Like
> FindPNG.cmake).
>
> Thanks for your help.
>

Sorry, it is FindOpenAL.cmake that uses the form <prefix>_LIBRARY instead of
<prefix>_LIBRARIES like I believe it should be doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090114/a5ef691d/attachment.htm>