# Generated libraries, not sources.

**URL:** <https://discourse.cmake.org/t/generated-libraries-not-sources/458>\
**Category:** Code\
**Created:** [January 7, 2020, 4:20pm UTC](https://discourse.cmake.org/t/generated-libraries-not-sources/458 "2020-01-07T16:20:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![alex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/alex/32/125_2.png) [@alex](https://discourse.cmake.org/u/alex)\
**Post date:** [January 7, 2020, 4:20pm UTC](https://discourse.cmake.org/t/generated-libraries-not-sources/458/1 "2020-01-07T16:20:06Z")

</div>

We are trying to move our build system from GNU Make to CMake and have run into issues defining an unconventional part of our build. This pattern repeats itself multiple places, so it would be useful to write a function or macro (or several) to set this up.

First, we take a collection of C++ sources and compile them together with some set of dependencies to produce a **generator**. This much is easy to do via the usual `add_executable` command.

Second, the generator is capable of producing multiple shared (sometimes static, controlled by command line args) libraries, along with their associated headers. We use LLVM to do this. It is run once for each library it is capable of producing.

This second part is what I’m having trouble defining. The libraries that are produced might have distinct usage requirements like defines, other library dependencies, etc. that would be nice to implement via `INTERFACE` properties. But it isn’t clear to me how to use `add_library` or similar to tell CMake about the generated library and also make sure the right command is run to generate it.

---

<div class="post-metadata">

**Author:** ![kyle.edwards](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/k/65b543/32.png) [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)\
**Post date:** [January 7, 2020, 4:32pm UTC](https://discourse.cmake.org/t/generated-libraries-not-sources/458/2 "2020-01-07T16:32:01Z")

</div>

> [@alex](#):
>
> Second, the generator is capable of producing multiple shared (sometimes static, controlled by command line args) libraries, along with their associated headers. We use LLVM to do this. It is run once for each library it is capable of producing.

Interesting. What is your use case? Is there perhaps some way it can be converted into a traditional `add_library()` style library with a traditional C/C++ compiler?

My other suggestion would be to create an `IMPORTED` library with the `IMPORTED_LOCATION` as the output of your LLVM-based generator, and then use `add_dependencies()` to add the dependency on the custom command/target.

---

<div class="post-metadata">

**Author:** ![alex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/alex/32/125_2.png) [@alex](https://discourse.cmake.org/u/alex)\
**Post date:** [January 7, 2020, 4:57pm UTC](https://discourse.cmake.org/t/generated-libraries-not-sources/458/3 "2020-01-07T16:57:06Z")

</div>

> [@kyle.edwards](#):
>
> Interesting. What is your use case? Is there perhaps some way it can be converted into a traditional `add_library()` style library with a traditional C/C++ compiler?

The generators’ use case is producing really tightly optimized image processing and NN kernels. Since they write LLVM IR directly, we never have C/C++ sources for the contents of the generated libraries, so I don’t think this is an option.

> [@kyle.edwards](#):
>
> My other suggestion would be to create an `IMPORTED` library with the `IMPORTED_LOCATION` as the output of your LLVM-based generator, and then use `add_dependencies()` to add the dependency on the custom command/target.

This seems more promising. I’ll give it a shot, thanks.