[cmake-developers] EXPORT dependency handling
Roger Leigh
rleigh at codelibre.net
Wed Jan 20 14:42:27 EST 2016
On 20/01/2016 19:05, Brad King wrote:
> On 01/20/2016 11:57 AM, rleigh at codelibre.net wrote:
>> 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.
>
> The difficulty of this problem is why we defer responsibility to project
> code to provide the imported targets for dependencies of exported targets.
> There are so many ways of making imported targets available I don't think
> it can be solved in general, but perhaps it can be made to work in common
> cases (at least optionally) with some kind of mapping as you propose.
Agreed that it's not going to be possible to do the mapping
automatically. Maybe allowing it to be specified manually as a target
property would be acceptable though. We could have a property for the
name to pass to find_dependency/find_package, and another for a minimum
version, which EXPORT could use, if set, to automatically add
find_dependency statements. We could set these in the Find* modules
when we create the imported interfaces, and they could also be set on
targets in the source tree as needed.
>> 2) the need to create the interface library target.
>
> I don't understand what you're saying here. What interface library target
> needs to be created in what context? Please provide an example.
Sorry for not being clear, it was at the end of the URL. I'll copy the
whole thing, since it's short (OMEBioFormatsConfig.cmake):
include(CMakeFindDependencyMacro)
find_dependency(OME REQUIRED COMPONENTS Common XML)
find_dependency(Boost 1.46 REQUIRED COMPONENTS boost iostreams
filesystem)
find_dependency(TIFF REQUIRED)
include(${CMAKE_CURRENT_LIST_DIR}/OMEBioFormatsInternal.cmake)
add_library(OME::BioFormats INTERFACE IMPORTED)
set_target_properties(OME::BioFormats PROPERTIES
INTERFACE_LINK_LIBRARIES ome-bioformats)
It's the last two lines. Internally, the target name is ome-bioformats,
but I actually want it to be OME::BioFormats as the name of the imported
interface. I don't have any need for "ome-bioformats" to be exported at
all, but EXPORT only allows a real target. Unless I missed a
workaround; I tried exporting ALIAS names and interface names, but
without success.
Ideally, if these two issues can be resolved, it will be possible to
emit a fully-functional exported configuration file which will work
without the need for custom wrapper code to fix up these things.
Regards,
Roger
More information about the cmake-developers
mailing list