Pre-coffee irrational idea, but thought why not put it out there for discussion anyway.
A single library target can be built as static or shared, but not both. This presents problems for some consumers who specifically need one or the other. It gets more complicated when the consumer itself might have switchable behavior which can select whether it wants to consume static or shared libs. Projects that want to support such flexibility have to create two separate targets, one for the static lib and another for the shared lib. That leads to different targets appearing as dependencies for the consumer, which can in turn complicate things like installing, exporting, packaging, etc.
While it is possible to find a way through the above scenario and others like it, I’m wondering if we could do better. Could we have a boolean target property that specified to build both static and shared versions of a target? That would definitely have lots of consequences, but let’s spit-ball it and see how far we get.
- Consumers could have a target property that selects whether they prefer to link to static or shared libs, where there is a choice. This should be on the consumer, not on the provider.
- I suspect we would still want to designate such libraries as having their
TYPEtarget property set to
SHARED_LIBRARYto avoid breaking user projects. It’s just that the target can also provide a static library. The requirements on a shared library are likely to be a more constrained set than static (e.g. the need for position-independent code). In other words, consider it a shared library, but with extra build artefacts for static. We’d probably have to add some new target properties to support these “extra” things.
- We may be able to use the one set of object files for both. That could be a really nice feature, saving duplication.
- A single
install(TARGETS)rule could install both the shared and static library bits. Not sure how we’d deal with Windows and the import lib for the DLL clashing with the static lib. That’s an open question for discussion.
I’m sure there are a lot more consequences, but let’s see what discussions the above triggers.