[CMake] Confusion on how find_package works.

[Philip Lowman]

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

> 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.


It's not the only one.  There are many modules that lack _LIBRARIES.
Somebody needs to fix them all but there is some confusion over how
_LIBRARIES works that needs explaining (sorry to hijack your thread).

Most of the Find Modules do this:

IF(FOO_FOUND)
   SET(FOO_LIBRARIES ${FOO_LIBRARY})
ENDIF()

I have been advised to do this (and I prefer it)

SET(FOO_LIBRARIES ${FOO_LIBRARY})

Can we get some clarification on this?  The former form will not cause an
error if someone links a target against ${FOO_LIBRARIES} because
FOO_LIBRARIES will be undefined and not set to FOO-NOTFOUND.  Is this by
design?  Is there a good reason to do this I'm not aware of?

Is the rationale to allow user code to be shorter, like this?

target_link_libraries(foo baz bimble blagojevich ${FOO_LIBRARIES}
${BAZ_LIBRARIES})

At first glance someone new to CMake might have no clue that FOO_LIBRARIES
or BAZ_LIBRARIES might be optional depedencies and be empty variables.
Wouldn't it be better to encourage users to write code like this?

target_link_libraries(foo baz bimble blagojevich)
IF(FOO_FOUND)
   target_link_libraries(foo ${FOO_LIBRARIES})
endif()
if(BAZ_FOUND)
   target_link_libraries(foo ${BAZ_LIBRARIES})
endif()

And if that is the case, wouldn't a good default for the future be to simply
do this in all new modules?
SET(FOO_LIBRARIES ${FOO_LIBRARY})

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090114/a424b80e/attachment.htm>