> On 01/19/2016 12:43 PM, Sam Thursfield wrote: >> Imported targets are now the recommended way of dealing with external >> library dependencies. > > Thanks! Applied with minor doc format fixup and merged to 'next' > for testing: > > FindPNG: Create an imported PNG::PNG target (#15911) > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9451ea5a > >> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") > > Shouldn't this refer to zlib instead of png libraries again?
I would have expected something like set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES ZLIB::ZLIB) after all of the "if(EXISTS... add imported link interface/location" blocks, so you get the appropriate zlib library. Certainly, I don't think PNG_LIBRARIES is appropriate to use for any of the imported targets, otherwise the system-specific zlib library path is going to get embedded in exported configuration when you call install(... EXPORT) to export the library configuration for find_package. I'd just use PNG_LIBRARY here and then add the dependencies as imported targets. As an aside, I've found some limitations in the usability and utility of EXPORT. These are two of the missing pieces for making the exported configuration functional: 1) is the need to manually call find_dependency for each of the interface libraries being exported. I work around this with wrapper scripts, for example: https://github.com/openmicroscopy/bioformats/blob/develop/cpp/lib/ome/bioformats/OMEBioFormatsConfig.cmake Here we find our dependencies, then include the generated configuration. The thing is, this is a duplication of our requirements from when we called find_package for each of those dependencies. If cmake could store a mapping from imported name to the FindXXX file which created it, this could also be automatically embedded in the exported file; it could even include the minimum version we need. And it also means the dependencies can never become inconsistent as we change them. 2) the need to create the interface library target. We export a target, not an interface name, and so the internal target name in our project is exposed to the user of the library. It would be nice if we could specify the friendly interface name we expect the user to use when we do the export, and ignore the internal target name for the generated output entirely. Kind regards, Roger -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
