COMPILE_PDB_NAME should default to OUTPUT_NAME, as PDB_NAME does

At the moment, if PDB_NAME isn't set, the PDB name is correctly derived from OUTPUT_NAME, taking into account PREFIX. COMPILE_PDB_NAME, however, isn't. The documentation says "unspecified" - is there a reason for this behavior?

Setting it manually is complicated by the fact that it doesn't accept generator expressions, so it's not possible to just reference $<TARGET_FILE_BASE_NAME:${LIB}>. It does have configuration-specific variants, but when (as in my case) OUTPUT_NAME itself is a complex generator expression, this unfortunately doesn't help.

IIRC the reason the default is unspecified is that not setting it means we pass only the directory to the compiler and let MSVC generate the file name. This is what .vcxproj files and MSBuild do by default.

The behavior I'm seeing is that, when OUTPUT_NAME is set, the name of the produced .lib file changes, but that of the produced .pdb file does not.

When CMAKE_LIBRARY_OUTPUT_DIRECTORY is set, this has the secondary effect of not copying the produced .pdb file to the output directory (presumably because the name doesn't match.)

(When OUTPUT_NAME is not set, the .pdb file is copied to CMAKE_LIBRARY_OUTPUT_DIRECTORY.)

A simple project demonstrating the issue:

CMakeLists.txt:

cmake_minimum_required(VERSION 3.5...3.16)
project(Lib CXX)

set(CMAKE_BINARY_OUTPUT_DIRECTORY "stage/bin")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "stage/lib")
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "stage/lib")

add_library(lib1 lib.cpp)

add_library(lib2 lib.cpp)
set_target_properties(lib2 PROPERTIES OUTPUT_NAME "lib2_mt_x64")

lib.cpp:

int lib_f()
{
    return 0;
}

Result:

 Directory of C:\tmp\compile_pdb_name\__build__\stage\lib\Debug

13.01.2020  18:04    <DIR>          .
13.01.2020  18:04    <DIR>          ..
13.01.2020  18:04             2,112 lib1.lib
13.01.2020  18:04            77,824 lib1.pdb
13.01.2020  18:04             2,112 lib2_mt_x64.lib

Thanks for the example. I tried that with the Visual Studio 16 2019 generator. The only difference between the lib1.vcxproj and lib2.vcxproj files is the names given. There is no change in the fields generated by CMake. In fact updating the example with

-set_target_properties(lib2 PROPERTIES OUTPUT_NAME "lib2_mt_x64")
+set_target_properties(lib2 PROPERTIES OUTPUT_NAME "lib2")

produces identical behavior for both targets even though one has OUTPUT_NAME set and the other does not. CMake is not changing behavior based on this setting.

This difference in behavior must be something about how MSBuild behaves.

FWIW, setting

set(CMAKE_COMPILE_PDB_OUTPUT_DIRECTORY "stage/lib")

causes the .pdb to show up for both libraries regardless of OUTPUT_NAME setting.

Yes, you are correct, this does seem to be MSBuild behavior, rather than CMake behavior.

My problem remains though; I need lib2_mt_x64.pdb to appear in the output directory, when OUTPUT_NAME is a generator expression, and there doesn't seem to be a way to do that.

Please post an example showing the OUTPUT_NAME generator expression you want to use.

I'm duplicating Boost's current name mangling, so it's a bit complicated: https://github.com/boostorg/cmake/blob/62d7fb264b33e54041d59ea477671072d7185ccb/include/BoostInstall.cmake#L95-L109

On second thought, since MSVC_RUNTIME_LIBRARY is actually set by me as well, here: https://github.com/boostorg/cmake/blob/62d7fb264b33e54041d59ea477671072d7185ccb/include/BoostRoot.cmake#L30-L38

I could probably get away with setting the COMPILE_PDB_NAME_<CONFIG> properties. It's not quite right, but it will probably work in practice.

We hit a related issue in c-ares too, where we would get errors like:

fatal error C1041: cannot open program database 'C:\projects\c-ares\build\bin\vc140.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS

This was mainly observed in AppVeyor and only occasionally, but of course annoying as it makes our CI workflow report failures.

Its not related to /FS however, which CMake appears to automatically add already, its because multiple targets are being built in parallel, but are trying to use the same pdb file. Using the suggestion in the subject of this ticket would have alleviated this issue.

https://github.com/c-ares/c-ares/pull/870

mentioned in issue #26670