CMake: Specify a DEBUG_LIBNAME_SUFFIX by default?

[nmlgc]

Describe the bug
When doing a CMake install of both Debug and Release versions into the same directory (which is the typical case, at least on Windows), the library of the configuration installed last overwrites the one installed last.

To Reproduce
Steps to reproduce the behavior:

1. Create a new CMake build configuration for any recent Visual Studio. Make sure that JSONCPP_WITH_CMAKE_PACKAGE is ON.
2. Install both Debug and Release versions. From the command line, it'd be

cmake --build . --target install --config Debug
cmake --build . --target install --config Release

3. The install directory will only have a single jsoncpp.lib, the one for the Release configuration.
4. Include jsoncpp in your application like any other CMake package:

include("${JSONCPP_CMAKE_BUILD_PATH_FROM_STEP_ONE}/lib/cmake/jsoncpp/jsoncppConfig.cmake")
target_link_libraries(MyProject jsoncpp_lib)

5. Linking a Debug version of MyProject fails, since the only existing jsoncpp.lib references the Release version of the C++ runtime.

Expected behavior
Both configurations should work from the same install, without requiring any more CMake code from users of the library.

Desktop (please complete the following information):

• OS: Windows 10
• CMake version: 3.15.4

Additional context
This is probably what #833 was mainly about. Setting a suffix upstream seems to be the best practice for handling this – at least that's what curl ended up doing after quite a bit of discussion on their issue tracker (see curl/curl#1857 (review) and the other issues linked from there).

I would have made this a pull request, but apparently, doing this breaks CMake's own Find* modules, which then need to be manually made aware of the change, effectively requiring a new CMake version for the change to fully propagate. So I guess I just leave this here as a bug report, and a notice for everyone affected to keep working around this issue…

If this is fixed though, it would be even better stylistically to use the standard CMAKE_DEBUG_POSTFIX variable in the same way curl does it (see curl/curl#2121 (comment)). Searching for DEBUG_LIBNAME_SUFFIX on both GitHub and Google reveals that it has become jsoncpp's own "not invented here" version of the same feature. (Then again, as a custom variable, it is shown in the GUI, unlike CMAKE_DEBUG_POSTFIX…)

[dota17]

@hjmjohnson could you take a look at this?

[hjmjohnson]

I highly encourage you to submit a pull request. That will start the ball rolling.

I don't have time to properly address this issue, and I have very limited access to windows computers.

Here are hints that I would follow

=== https://stackoverflow.com/questions/49672264/cmake-add-d-suffix-for-debug-build-of-static-library?noredirect=1&lq=1

CMAKE_DEBUG_POSTFIX is used for appending the d for debug libraries:

set(CMAKE_DEBUG_POSTFIX d)
If you do not want to set this globally, you can also use the DEBUG_POSTFIX target property instead on selected libraries.

There is no corresponding feature for distinguishing 32/64 bit builds, but since it is impossible to mix those two in the same CMake configuration, you can easily distinguish those cases manually, e.g.

if(CMAKE_SIZEOF_VOID_P EQUAL 4)
set(ARCH_POSTFIX "")
else()
set(ARCH_POSTFIX 64)
endif()

add_library(my_lib${ARCH_POSTFIX} [...])
Or, if you want to use the same target name on the different architectures, set a variable like CMAKE_STATIC_LIBRARY_SUFFIX (there exist a whole bunch of them, so you can select the correct one for your target type and based on which output files you want to append a suffix to).

And since you also mentioned this answer for finding such libraries: Prefer using imported targets instead of the coarse-grained legacy debug and optimized qualifiers for target_link_libraries. Config file packages provide a convenient way of exposing such imported targets to your clients, and they also handle any suffix shenanigans automatically for you.

====
https://cliutils.gitlab.io/modern-cmake/chapters/install/installing.html