How do you install plugins when building with a static triplet?

[jpgaribotti]

I have a port that is structured as a library that can load plugins. The library itself can be built and linked either dynamically or statically, controlled by CMake's BUILD_SHARED_LIBS, but the plugins use add_library(plugin-name MODULE) and so are always built as shared libraries. This is intended. Which plugins to load is decided at runtime, and they can't be statically linked.

Using a triplet with VCPKG_LIBRARY_LINKAGE=dynamic works as expected, but when using VCPKG_LIBRARY_LINKAGE=static the plugins are built (can be found in the bin/ folder in the port's buildtree location) but they're not installed into the dependent project.

Is this behavior by design? How can I copy the plugins (shared libraries) created during a static build?

[dg0yt]

• A static library is not linked. Any usage requirements have to be carried along in separate files. CMake or pkg-config can do this for link libraries. But...
• Plugins are not linked into other binaries - there are no link libraries. Even with dynamic linkage, you cannot look at a DLL or EXE and tell which plugins it would use. And so in general, plugins are not copied into dependent projects even for dynamic linkage unless...
• Sometimes there are deployment tools or scripts which do the copying, based on informed guessing. (Example: windeployqt.)
• If there is no support tool, you simply have to collect and deploy the plugins in your own scripts.

[jpgaribotti]

I'm not sure what you mean by "A static library is not linked". Every resource I've ever read refers to building a binary with a static library as "statically linking" the static library. But the issue is not with linking the library.

I also didn't said the plugins would be linked, I said they were meant to be built as dynamic libraries and loaded at runtime, which is basically how the documentation for dlopen describes it. But again, the issue is not about the behavior during the build or at runtime.

The issue is that the plugins are not available after being built. One issue I found after some more research is that the plugins had been set to install to CMAKE_BINARY_DIR instead of CMAKE_INSTALL_BINDIR. When set to CMAKE_INSTALL_BINDIR, the plugins were then available in the bin/ folder as expected. A different issue then cropped up, however, as the references in the target file were set to the tools folder, apparently by the vcpkg_cmake_config_fixup command in the portfile. When the target file is then read, the build fails because the references were moved but the files are not in the tools folder.

Looking at the installation directory layout, it looks like the correct install location should be plugins/. So that might be the solution to the issue.

[dg0yt]

One issue I found after some more research is that the plugins had been set to install to CMAKE_BINARY_DIR instead of CMAKE_INSTALL_BINDIR.

I think you showed that the problem is that the upstream package doesn't install plugins when configured for static libs. This is not a vcpkg issue.
(In that case there is the second question if upstream supports plugins when configured for static libs.)

What I originally tried to explain is that plugins need to moved around explicitily.
First from the package build to the vcpkg install tree. (Expected from upstream's installation. But the port maintainer may add explicit steps.)
Second from the vcpkg install tree to the packaged/deployed app. (App developer responsibility. Might be facilitated specific support tools.)