CODEWITHSUNDEEP
c++dlllibraries
Dennis
Dennis

Reputation: 155

compile dependencies into a library itself

I want to provide a large library I programmed (further called "my lib") to another developer who is building a larger application (further called "target application"). My lib is under very experimental development and I may change dependencies, versions of those, etc. quite often. To call the developer of the target application every other week to change dependencies looks like an unclean option to me. It would be very nice, to just exchange a single (or a couple of) file(s) that include all of my dependencies, which brings me to my question:

Is it possible for me to compile all of my dependencies into the library I'm building in such a way that the developer of the target application will not have to include the header files, dlls libs, etc. of the dependencies of my lib?

Something similar is possible for executable files, where staticly linked libraries will be compiled into the executable.

Is something similar possible for this use-case? I say "library" on purpose because I dont care if it results in a DLL or staticly linked file.

Thanks in advance!

Upvotes: 0

Views: 1030

Answers (1)

Guillaume Racicot
Guillaume Racicot

Reputation: 41780

The real answer is this: use a proper dependency manager.

Ensure you have a proper build system setup where no matter the usage requirement change, no changes are required for projects down the line. Coupled with a dependency manager, it won't matter how your usage requirement are: the user will only update the library and the tools take care of the rest.

CMake exported targets are excellent for this kind of purpose. A proper package manager such as vcpkg can completely handle this with a custom repository.

Now for the boring and unoptimal answer.

What you could do is compile your library in a dynamic library. Only update the DLL and the headers and ask statically linked libraries will be updated too, since they are statically linked into the DLL.

However, when doing this, you expose yourself to some problems:

First, you'll most likely have to ship you libraries headers too, or even compile definition. This might change usage requirements of your library. To hide all of this, you may need to wrap all your classes in pimpl wrappers. This will prevent you from using many features, such as templates or constexpr.

Second, the moment you ship your library as a DLL, you expose yourself to ABI. Users will attempt to only update the DLL without recompiling, and any ABI compatibility issues will be brought up. Adding a virtual function, changing the name of a function, adding a member to a class, changing the meaning or the result of a function, even fixing a bug can result in an ABI break.

Upvotes: 1

Related Questions