Hi Rick, Thanks for looking at this issue.
FYI, module patches need to be reviewed and committed by the corresponding module maintainers: http://www.cmake.org/Wiki/CMake:Module_Maintainers Please clone from git: http://www.cmake.org/Wiki/CMake/Git#Cloning and commit a separate topic branch locally for each module. Then you can use "git format-patch" to extract a patch with commit message to send to each maintainer and this list. On 05/25/2011 03:47 PM, Rick Yorgason wrote: > (Reposting after my first post didn't get through because I hadn't > subscribed to the list first. Apologies if this gets duplicated.) > > There's a suggestion in Modules/readme.txt and this post: > > http://www.cmake.org/pipermail/cmake/2010-February/035085.html > > that the FindXXX.cmake files should offer XXX_RUNTIME_LIBRARIES and > XXX_RUNTIME_LIBRARY_DIRS variables to let you know where the DLLs for a > library are, so I've added that feature for ZLIB, LibXml2, and LibXslt. > Patches below. The readme also says that the values should not be cache entries. You need to use singular names in find_* commands and combine the results into lists with plural names. Also, the libraries are only separate on Windows so you actually need different logic paths to produce the right runtime path entry for each platform. For example: IF(WIN32) FIND_FILE(LIBXML2_DLL NAMES libxml2.dll PATH_SUFFIXES bin) MARK_AS_ADVANCED(LIBXML2_DLL) GET_FILENAME_COMPONENT(LIBXML2_RUNTIME_LIBRARY_DIRS "${LIBXML2_DLL}" PATH) ELSE() SET(LIBXML2_RUNTIME_LIBRARY_DIRS "") # trust RPATH? ENDIF() > It should be noted that these variables will become more useful if we > get a couple changes in CMake: [snip] > http://www.kwwidgets.org/Bug/view.php?id=8884 AFAIK no one is actively working on issue 8884. > As far as XXX_RUNTIME_LIBRARIES, that's best used in INSTALL(FILES) IMO installing dependencies found on the system is outside the scope of a build system. It already found them on the system so they are already installed. This lies in the realm of package management. I think trying to provide XXX_RUNTIME_LIBRARIES is much more trouble than just the runtime directories. One never knows what transitive runtime dependencies lie behind a library. > Also, I only did this for .dll files and not .so files. There's no > reason we couldn't, but it would be only marginally useful on > non-Windows platforms, since it's not typical to ship copies of shared > libraries on other platforms. It is less important on non-Windows platforms as noted in the example above. -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
