But now I’m re-evaluating some of my CMake configurations and I see that CMAKE_MSVC_DEBUG_INFORMATION_FORMAT is the preferred way to set the /Zi option. However when I do that it only sets the compiler flag and not the required linker /DEBUG flag which actually makes the linker generate the PDB file.
I’ve read through the “Add abstraction for debug info” bug and related links but haven’t found a definitive answer to this, and the issue seems to be stalled?
You set CMAKE_<LANG>_LINK_FLAGS_<CONFIG> to whatever you want for a particular build. If you want /DEBUG in the link flags for Release builds, you set -DCMAKE_CXX_LINK_FLAGS_RELEASE="/DEBUG" when producing that build.
You can manage collections of such options either using your IDE’s native CMake configuration integration, or using CMake Presets.
I want this to be a default flag for the project, where I generate the Visual Studio solution, and when I build the Release configuration in the IDE it will always generate PDBs.
There will never be a time when I do not want to generate PDBs, even for “Final” release builds.
Then put that in the bash script you use to invoke CMake or put it in a preset.
You don’t put your warning flags as pragmas in the source code, even though that would make sure the warning flags always get enabled correctly, because warning flags should be controlled on the compiler command line. Not by source code pragmas.
You don’t put transient build flags in the project description, even though that would make sure the transient build flags get enabled correctly, because the transient build flags should be controlled by the build system command line. Not by the project description.
I heartily disagree, emitting PDB files is not a transient thing, it is part of the specification of what the project generates as its regular output, just like specifying that it emits an executable or a library. I cannot imagine a case where you would not want to emit PDB files in all build configurations, you may not want to package it for your customers but you for sure need it for your own benefit now and later to debug the code that you ship.
I understand from the replies that the only way to get PDBs being generated is by setting the linker flags manually and then either setting the compile flag manually or by using CMAKE_MSVC_DEBUG_INFORMATION_FORMAT.
All of these are transient, and may be changed from user-to-user who produces the build. Some users might want /Z7, and embed the PDBs in the binaries.
It is the same with compiler warnings, optimizations, and output locations. It would be odd to write these into the source code, as the user producing the build should have control over them.
That may be the case when the source code is for a library that is distributed to third parties that then make modifications and integrate it with their own products which they ship. In that case I agree, if you distribute libraries in source code form, you should leave the compilation settings of those libraries to the people using them.
In this case I am the user producing the build.
I am configuring a project which builds a bunch of executables (and libraries for those executables), which I then package and distribute myself. I want to keep all of the compiler settings as close together as possible, therefore I’m using a toolchain file for each platform, where I put all build settings within.
So that is why I am asking if there is a more canonical way to specify that I require the debugging symbols sidecar file be emitted in all build configurations. There is a flag for specifying the format of the debugging file but it doesn’t affect the linker settings at all, and so the PDB is only present in some cases.
Agreed, when the only person who builds the code ever is yourself, you can basically do whatever works for your workflow.
But the tools are designed around the generic case, CMake exists to facilitate portable builds by many users in many different build environments.
This is why the low friction path is controlling these things via presets, and there are incomplete facilities for many of the abstractions around PDB or debug information flags generally.
In your case, you’re not missing anything. There is not some hidden knob for passing the linker flag.