[CMake] Confusion on how find_package works.

[Miguel A. Figueroa-Villanueva]

On Wed, Jan 14, 2009 at 11:51 PM, Robert Dailey wrote:
> On Wed, Jan 14, 2009 at 4:20 PM, Miguel A. Figueroa-Villanueva 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?

Well, yes print path_list. I'm simply suggesting to verify your list.

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

Well, I don't know about libfind_process, but none of the modules
shipped with CMake use it. Again your primary source of information to
properly write a find module should be the Modules/readme.txt
(http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup).

Note that <prefix>_LIBRARIES should contain the list of libraries that
your target will link (with full paths). This is usually not a CACHE
variable, but a collection of all the libraries found using
find_library for example. So, if you have wxpng.lib and wxregex.lib in
directory C:/wxWidgets/lib/vc_lib, then you can do the following:

------------- FindWX.cmake -----------------------
...
find_library(WX_PNG_LIBRARY wxpng PATHS C:/wxWidgets/lib/vc_lib)
find_library(WX_REGEX_LIBRARY wxregex PATHS C:/wxWidgets/lib/vc_lib)

set(WX_LIBRARIES ${WX_PNG_LIBRARY} ${WX_REGEX_LIBRARY})
...
------------- FindWX.cmake -----------------------

Note that this is a trivialized example to show how find_library,
<prefix>_LIBRARY, and <prefix>_LIBRARIES should work. Remember that
you need to inspect the results of these to set <prefix>_FOUND.

Again, refer to the readme.txt for the appropriate behaviour and NOT
the current find modules since many do not follow the guidelines
exactly, and in some cases will not follow them in the future due to
backwards compatibility.

--Miguel