MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016071CMakeCMakepublic2016-04-19 13:022016-06-10 14:21
ReporterItai Seggev 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product VersionCMake 3.5.2 
Target VersionFixed in Version 
Summary0016071: CMake should map /Fd to COMPILE_PDB_NAME for static libraries
DescriptionThis is a follow up to https://cmake.org/Bug/view.php?id=14763 [^] and its predecessors https://cmake.org/Bug/view.php?id=14060 [^] / https://cmake.org/Bug/view.php?id=14062 [^]

/Fd was separated from PDB_NAME, because normally what we want is the linker pdb. However, if our final product is the static library, then we do want to the compiler PDB file, so COMPILE_PDB_NAME was added. Yet, a mapping was not added between COMPILE_PDB_NAME and /Fd. The result is /Fd is added to compile flags but COMPILE_PDB_NAME remains at its default value, and an inconsistency is created between Visual Studio and NMake generators. For the former, the flag is honored, but for the latter it is overridden by the NMake file's own specification of /Fd. Thus, for dlls and exes, you can simply add /PDB to the link flags, but for static libraries you must manually manipulate the COMPILE_PDB_NAME property for the target. I think that /Fd, certainly for static libraries which have no link step, should be mapped to COMPILE_PDB_NAME.
Steps To ReproduceCreate a minimal CMakeLists.txt like the following:

project(foo)
add_library(myLib STATIC myLib.c)
target_compile_options(myLib PUBLIC $<$<PLATFORM_ID:Windows>:/Zi /FdmyLib.pdb>)

Generate a NMake Makefiles build system and build. You will see

cl : Command line warning D9025 : overriding '/FdmyLib.pdb' with '/FdCMakeFiles\myLib.dir/'

and the PDB file is indeed CMakeFiles\myLib.dir\vc120.pdb. If you generate a Visual Studio project and build, there is no warning and the pdb file is .\myLib.pdb.

And indeed the pdb file will be
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-04-19 13:02Itai SeggevNew Issue
2016-04-19 13:19Brad KingNote Added: 0040892
2016-04-19 23:03Itai SeggevNote Added: 0040896
2016-04-20 08:53Brad KingNote Added: 0040897
2016-04-20 08:53Brad KingStatusnew => resolved
2016-04-20 08:53Brad KingResolutionopen => won't fix
2016-06-10 14:21Kitware RobotNote Added: 0041189
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040892)
Brad King   
2016-04-19 13:19   
CMake doesn't do flag mapping in the non-IDE generators. The object compilation command line for Makefile (and Ninja) generators is specified in the internal CMAKE_<LANG>_COMPILE_OBJECT variable:

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Windows-MSVC.cmake;hb=v3.5.2#l288 [^]

It hard-codes /Fd to be whatever COMPILE_PDB_NAME tells it to be.

Why can't you set COMPILE_PDB_* options to get what you want? That is the documented interface for this.
(0040896)
Itai Seggev   
2016-04-19 23:03   
I can and do set COMPILE_PDB_NAME. However, it seems strange to me that some compile flags are set by target_compile_options whereas others can only reliably be set using set_target_properties. It is moreover strange that flags set in target_compile_options are respected by some generators (VS) and not others (NMake). Why don't my compile flags override the default ones?
(0040897)
Brad King   
2016-04-20 08:53   
Re 0016071:0040896: The VS generator supports the flag override by an accident of its implementation. That undocumented behavior works in one generator does not mean that it works in all generators.

Commands like target_compile_options are for providing flags for which CMake does not otherwise have an abstraction. The documented way to control the location of the compiler .pdb file is with COMPILE_PDB_* properties:

 https://cmake.org/cmake/help/v3.5/prop_tgt/COMPILE_PDB_NAME.html [^]
 https://cmake.org/cmake/help/v3.5/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY.html [^]
(0041189)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.