Hi,
I know the file API’s purpose is intended mainly for IDE’s. However I wonder if CMake also exposes the install targets via the file API? Basically I need all information about targets which get exported (and their install location, their interface include directories, link libraries, definitions, …). Or is there another way to extract all that information in an easily parsable format? (Parsing generated <package>Targets.cmake seems not so trivial).
Thanks for the info!.
The fileapi codemodel-v2 object does have a little information about target installations, but it does not include the public interface and usage requirements. Most of the fileapi information corresponds to build tree information, but <package>Targets.cmake files typically come from install(EXPORT) which is for the install tree.
I’ve opened CMake Issue 20106 to document and track the status of alternative formats for install(EXPORT) that could be more accessible to non-CMake clients.
Thanks a lot for the information. I am scanning through the links provided in the issue and it seems to me that the CPS format would be great - I seems to describes the same information that is provided by an install(EXPORT), but in an easily parsable format.
I have far too little knowledge about pkg-config, but apart from being widely adapted in the Unix world, its flat hierarchy and current format seems to have little in common with a the idea of a CMake packages with different components.
Is anyone actually working on realizing an alternative CMake export, or is this mainly brainstorming at the moment?
The background why I am asking is that Conan (https://conan.io/), a C++ dependency management system, requires package recipes to specify a lot of information which is already available via CMake install tree, and I’d rather export all this information from CMake than to specify it again in a Conan package recipe.
They even discourage the use of <package>Config.cmake files generated by CMake and prefer to generate those themselves for official packages, which I think is a wrong approach.
A common package specification which is generated and consumable by different build systems at some point would be fantastic.
I will follow the new issue on Github.