On Wed, Jan 14, 2009 at 10:54 PM, Robert Dailey <rcdai...@gmail.com> wrote:
> On Wed, Jan 14, 2009 at 9:51 PM, Robert Dailey <rcdai...@gmail.com> wrote: > >> >> >> On Wed, Jan 14, 2009 at 4:20 PM, Miguel A. Figueroa-Villanueva < >> migu...@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
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake