Add 'header-only' dependencies

[NNemec]

I have two ports 'library' and 'plugin'. Typically, 'plugin' is loaded at runtime, but to simplify installation, I would like to link it into the application. Technically, this is possible, either statically or dynamically, except for one missing vcpkg feature:

'library' provides header files needed to compile 'plugin', but before linking 'library', the output of the 'plugin' build must already exist. I would therefore need to be able to install just the headers of 'library' before building 'plugin' but defer the build of 'library' for later.

(The problem specifically exists for Windows dynamic linking, because linking a DLL requires all dependencies to be resolved by a .LIB import library. AFAIK on Linux, missing symbols would only be found at the final link time of the executable, so the problem would not exist.)

I am aware that this feature might require fundamental restructuring of vcpkg, so it might not be worth the effort for a rare situation. Still, I wanted to put this up for discussion...

[Neumann-A]

Question:
How would you solve this using CMake targets?

[NNemec]

One approach would be to split into 'library-interface' and 'library-implementation' to allow non-cyclic dependencies. I'm CMake, that would be straightforward. In vcpkg, it would require two ports, and either splitting the download or downloading it twice.

[Neumann-A]

vcpkg is basically CMake..... but it seems like your two ports are in reality one port with 3 exported targets.

[NNemec]

Not quite sure myself what this is.
To be concrete, it is about gdk-pixbuf and librsvg, the latter providing an optional pixbufloader-svg. Each of them is valuable on its own, so merging them into one port does not seem justified. Perhaps the other direction is better: breaking then apart into multiple ports, but allowing several ports to share the same download and source directory. Or extend the "Feature" concept to allow dependencies on subfeatures and separate builds of separate features.

[BillyONeal]

I'm not sure why this is requires:discussion; it doesn't seem like this is something we intend to investigate in the near term.

[JackBoosY]

Usually, the plugin must rely on the library or executable to use, if not, it can be turned into an independent target, as @Neumann-A said.