# Making a library that's importable with \`find\_package\` but includes targets for sources and pre-built .so

**URL:** <https://discourse.cmake.org/t/making-a-library-thats-importable-with-find-package-but-includes-targets-for-sources-and-pre-built-so/15314>\
**Category:** Code\
**Created:** [November 17, 2025, 10:16am UTC](https://discourse.cmake.org/t/making-a-library-thats-importable-with-find-package-but-includes-targets-for-sources-and-pre-built-so/15314 "2025-11-17T10:16:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattp](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mattp/32/5078_2.png) [@mattp](https://discourse.cmake.org/u/mattp)\
**Post date:** [November 17, 2025, 10:16am UTC](https://discourse.cmake.org/t/making-a-library-thats-importable-with-find-package-but-includes-targets-for-sources-and-pre-built-so/15314/1 "2025-11-17T10:16:15Z")

</div>

This is, I guess, a long gestation follow-up to a previous post of mine, [installing a SHARED IMPORTED library's symlinks and real library file](https://discourse.cmake.org/t/installing-a-shared-imported-librarys-symlinks-and-real-library-file/13112) .

The situation was that we were trying to package a library and a set of executables that had a prebuilt (via GraalVM’s `native-image` tool) C shared library dependency, together with the C/C++ sources for the library and executables.

What we ended up with there was generating a fake CMake project for the dependency whose build output could be combined with the `native-image` output to create a CMake Config-mode package that could be found by our actual CMake project for the C/C++ sources. With some hitting-with-a-hammer, this gives us the ability to make a binary package that comes with the right `ProjectConfig.cmake` files so that it can be included by a consumer, allowing us to ship the shared libraries and binary executables.

So far so good. I’ve been very focussed on trying to both make it easy to consume from a client’s CMake project, and have the utility executables runnable on install. I was not paying close enough attention to the C++ ABI problem, and now I’m realising that distributing a .so that exposes C++ classes is, uh, somewhat problematic.

What I am now having problems with is wanting to have my cake and eat it. I want to continue to distribute as pre-built binaries the library, its dependency, and the executables, as well as to distribute the library sources so that users can safely compile everything.

In the longer term I can look to refactor the C/C++ code so that there’s a cleaner API separation and the C++ library that consumers actually use could be a header-only shell, which would work just fine with the existing CMake project structure. In the short-to-medium term I want to find a way to do both. I’m hoping that there’s a simple way I’m missing and that describing the problem (and answering any follow up questions) will reveal it, but who knows…

Thanks!