# File API and exports

**URL:** https://discourse.cmake.org/t/file-api-and-exports/411
**Category:** Usage
**Created:** [December 18, 2019, 2:42pm UTC](https://discourse.cmake.org/t/file-api-and-exports/411 "2019-12-18T14:42:03Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Kerstin\_Keller](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kerstin_keller/32/180_2.png) [@Kerstin\_Keller](https://discourse.cmake.org/u/Kerstin_Keller)
#### Post date: [December 18, 2019, 2:42pm UTC](https://discourse.cmake.org/t/file-api-and-exports/411/1 "2019-12-18T14:42:03Z")

</div>

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!.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [December 18, 2019, 3:40pm UTC](https://discourse.cmake.org/t/file-api-and-exports/411/2 "2019-12-18T15:40:58Z")

</div>

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](https://gitlab.kitware.com/cmake/cmake/issues/20106) to document and track the status of alternative formats for `install(EXPORT)` that could be more accessible to non-CMake clients.

---

<div class="post-metadata">

### Author: ![Kerstin\_Keller](https://discourse.cmake.org/user_avatar/discourse.cmake.org/kerstin_keller/32/180_2.png) [@Kerstin\_Keller](https://discourse.cmake.org/u/Kerstin_Keller)
#### Post date: [December 19, 2019, 12:23pm UTC](https://discourse.cmake.org/t/file-api-and-exports/411/3 "2019-12-19T12:23:39Z")

</div>

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/](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.