On 24/07/17 21:07, Niall Douglas via Boost wrote:
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.
This is provably untrue.
It's entirely correct if you read what he was saying carefully. If you use a single target name "lib", this will be a shared library or a static library depending upon the build configuration (the BUILD_SHARED_LIBS option), or a header-only library. Supporting shared and static simultaneously isn't possible *with a single target name*. You would have to have e.g. "lib" and "lib-static". And on of the libraries e.g. the static library would need a mangled name since on Windows both the import library and the static library have a .lib extension and would clash with each other. Doing that is possible, but bad practice. The target names are mangled and not as usable downstream; downstream use has to commit to specific variants, and it's a lot less flexible. Choosing shared or static at configure time is the way cmake is designed to work, and it's the better choice here. (I have gone with the lib+list-static approach in the past and regretted it later.) Using normal fixed target names does not preclude mangling the binary name, which can be set independently as a target property. Roger