<div class="gmail_quote">On Wed, Jan 14, 2009 at 10:54 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><div class="gmail_quote">On Wed, Jan 14, 2009 at 9:51 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey@gmail.com" target="_blank">rcdailey@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div><br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 4:20 PM, Miguel A. Figueroa-Villanueva <span dir="ltr"><<a href="mailto:miguelf@ieee.org" target="_blank">miguelf@ieee.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Wed, Jan 14, 2009 at 5:54 PM, Andreas Pakulat wrote:<br>
> On 14.01.09 15:45:53, Robert Dailey wrote:<br>
</div><div>>> On Wed, Jan 14, 2009 at 1:20 PM, Andreas Pakulat wrote:<br>
>><br>
>> > If you look at the cmake docs, then you'll find out that nothing in there<br>
>> > states that wildcards are allowed. Hence I'd assume that wildcards are not<br>
>> > supported.<br>
>> ><br>
>> > Also you only need to set one of the two for find_path to use the<br>
>> > directory.<br>
>><br>
>> Well if only the CMake documentation was that reliable. There's information<br>
>> that I have found to be inaccurate or missing from the docs.<br>
><br>
> So far I haven't found inaccurate information myself, missing yes<br>
> sometimes.<br>
><br>
>> For example, the documentation for find_package() no where mentions the<br>
>> variable created for the COMPONENTS parameter. Looking at FindBoost.cmake,<br>
>> it appears to be in the form of <prefix>_FIND_COMPONENTS. Is this correct?<br>
><br>
> Apparently yes, but no idea where I got that from :) Would be good to<br>
> file a bugreport at <a href="http://www.cmake.org" target="_blank">www.cmake.org</a> as this is indeed missing in the docs.<br>
<br>
</div>Well, you can find it in the Modules/readme.txt file. However, the<br>
module user doesn't need to know about the <prefix>_FIND_COMPONENTS<br>
variable. This is for the FindXXX module developer. Also, note that<br>
maybe you find inconsistent the information in the find_package<br>
documentation, because of old or poorly written find modules that do<br>
not work as they should. However, the documentation for CMake in<br>
general is very reliable (although sometimes missing some).<br>
<br>
In your case, it seems you need to generate the list of paths to be<br>
searched appropriately (no wildcard) and then use something like this:<br>
<br>
find_path(<VAR> NAMES name PATHS ${path_list} NO_DEFAULT_PATH)<br>
<br>
That is, if you don't want to search in the standard directories. Make<br>
sure you appropriately handle spaces in directory names and print the<br>
generated list of paths to see where you are searching.</blockquote></div><br></div></div>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?<br>
<br>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).<br>
<br>Thanks for your help.<br>
</blockquote></div><br></div></div>Sorry, it is FindOpenAL.cmake that uses the form <prefix>_LIBRARY instead of <prefix>_LIBRARIES like I believe it should be doing.</blockquote><div><br>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).<br>
<br>Most of the Find Modules do this:<br><br>IF(FOO_FOUND)<br> SET(FOO_LIBRARIES ${FOO_LIBRARY})<br>ENDIF()<br><br>I have been advised to do this (and I prefer it)<br><br>SET(FOO_LIBRARIES ${FOO_LIBRARY})<br><br>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?<br>
<br>Is the rationale to allow user code to be shorter, like this?<br><br>target_link_libraries(foo baz bimble blagojevich ${FOO_LIBRARIES} ${BAZ_LIBRARIES})<br><br>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.<br>
Wouldn't it be better to encourage users to write code like this?<br><br>target_link_libraries(foo baz bimble blagojevich)<br>IF(FOO_FOUND)<br> target_link_libraries(foo ${FOO_LIBRARIES})<br>endif()<br>if(BAZ_FOUND)<br>
target_link_libraries(foo ${BAZ_LIBRARIES})<br>endif()<br><br>And if that is the case, wouldn't a good default for the future be to simply do this in all new modules?<br>SET(FOO_LIBRARIES ${FOO_LIBRARY})<br></div></div>
<br>-- <br>Philip Lowman<br>