[cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target

[rleigh at codelibre.net]

> 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