I'm working on a fairly substantial application and need to provide part of the functionality to other teams in the company as a static library (the main reason for the static library is to prevent conflicts with potential different versions of sub-libraries or different compiler versions/options).
I can statically link sub-libraries into my library by using the $<TARGET_OBJECTS:subLibName> syntax, as in example, below:
add_library(
MyLibrary STATIC
${MyLibrarySourceFiles}
$<TARGET_OBJECTS:SubLib1>
$<TARGET_OBJECTS:SubLib2>
)
But I'm at a total loss on how to include external libraries like e.g. crypt32 or libucrt.lib.
I'ld prefer to only provide a release version of the library as it makes deployment a bit easier (in my current attempts, I can't compile a debug version of a test application using MyLibrary because of a release/debug conflict between the VS runtime in the library and the application which I hope would be solved by linking MyLibrary against libucrt.lib).
I don't use CMAKE, but I can at least provide some info. There's a difference between crypt32 and libucrt.lib, so you need to handle them differently.
crypt32.dll is a Windows DLL - you'll find it in c:\windows\system32 - so you don't need to worry about it, the consumers of your library will already have it.
libucrt.lib is the C++ runtime and is supplied with the compiler, and there are two versions - static and dynamic. Each of these comes in two further versions, Debug and Release.
It's unfortunate, but MSVC mandates that you impose the constraint on the consumers of your library (or maybe they impose it on you) that you both build with the same flavour of runtime - static Release, say. Everything should then 'just work'.
I would add (if I understand you right) that I find it strange that the team developing the application don't (also) want you to supply a Debug build of your library, then they can build their app that way too. Debugging Release code can be a nightmare.