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