Wanted: Import support for custom targets (extra bonus: also export support)
If one has a non-code products in their buildsystem, thus uses add_custom_target()
, there is no built-in support in CMake for exporting such a custom target in CMake config files, so it could be imported and used in other projects.
While that would be good to have now and then. As there can be many non-code build products where CMake might be nice to use.
At least having a new option IMPORTED
for add_custom_target()
(like e.g. with add_library
) would be good to have for the start, so one can generate/write custom CMake config code which then will not result in rules in the build system generated by CMake, but still can be used to provide needed properties.
Use case:
ECMAddQch from KDE's Extra-CMake-Modules provides a macro to generate Qt Compressed Help (QCH) files with the docs of the public API of a library. If the library links to other libraries and uses things from those which then show up in the public API (e.g. base classes or types), one can integrate the generated documentation with the documentation for those other libraries, if they are also available as QCH files. To do that, one needs to reference those files during the documentation generation, with a few parameters per each QCH file of the other libraries.
To avoid having to explicitly specify all these parameters any time some other QCH file should be integrated with, the idea has been to apply the same concepts as used with code libraries: having a single target per QCH file which has all the needed parameters set as properties.
So like target_link_libraries()
just needs the target name of imported library targets and then automatically extracts and applies things like include paths, the macro ecm_add_qch()
just needs to get passed the target names of imported QCH targets and then gets all details from the the properties of those targets:
ecm_add_qch(MyLib_QCH [...] LINK_QCHS HisLib_QCH HerLib_QCH)
The lack of support for exporting custom targets is currently worked around by another macro ecm_install_qch_export()
, which simulates real target export to some degree by writing custom code into a file which then is to be installed and included by the CMake config files:
set(_content "${_content}
if (NOT TARGET ${_target})
add_custom_target(${_target})
set_target_properties(${_target} PROPERTIES
DOXYGEN_TAGFILE \"${_tagfile_installdir}/${_tagfile_name}\"
QHP_NAMESPACE \"${_namespace}\"
QHP_NAMESPACE_VERSIONED \"${_namespace_versioned}\"
QHP_VIRTUALFOLDER \"${_virtualfolder}\"
IMPORTED TRUE
)
set_property(TARGET ${_target} PROPERTY LINK_QCHS ${_linkqchs})
endif()
"
(see https://cgit.kde.org/extra-cmake-modules.git/tree/modules/ECMAddQch.cmake )
The property IMPORTED TRUE
is ignored by cmake itself of course and normal build rules are generated, so the build log is a little confusing due to all the "imported" targets showing up.
BTW, these two macros have been now deployed to all of the KDE Frameworks libraries and will be released begin of July, 2017. Example usage: https://cgit.kde.org/kjobwidgets.git/commit/?id=66510d55dbe0d50ba69a3115162a55ad2a112602 So this issue will be facing a few people around the globe, hopefully some with resources to give this a proper built-in CMake solution :)