libcpr
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS breaks all projects using the standard library with cpr
cpr uses the standard library and instantiates standard library templates. CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS sees these and exports them from cpr's dll. It's doesn't apply __declspec(selectany) to these symbols so they are strong. This means any library that links to a shared cpr on windows and tries to use the same standard library templates as cpr will not link. (this usually comes up with string).
This is why vcpkg has set cpr to build as a static lib only.
To fix this you should stop setting CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS and instead manually annotate the smybols to export. (you can annotate whole classes, but we really recommend annotating specific (member) functions instead if you want to maintain any kind of ABI. CMake has a GenerateExportHeader module that can help with this.
Ah, ok. Would you like to create a PR for this, since I'm not too much into Windows and vcpkg?
Maybe, the situation isn't as bad as I thought (although vcpkg will still disable dynamic builds if you set CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS). The problems with the standard library only really happen during interactions with other libs that do things like export standard library inline functions from their own dll via sneaky behavior of dllexport.
Usually the best way to go about this is adding two macros, something like CPR_EXPORT_CLASS and CPR_EXPORT FUNCTION and apply them to functions you want to export. The class version would expand to nothing on windows, and to __attribute__ ((visibility ("default))) on unixey systems, whereas the function macro would expand to __declspec(dllexport) on windows and __attribute__((visibility ("default))) on unix. Then you can set the default visibility to be hidden even on unix and reduce your export surface, sometimes substantially.
I'm not sure I'll have time to prepare a PR, but I can help review one or clarify how these things work.