Re: [Boost-build] an implementation of msvc pdb file management for msvc.jam

Subject: Re: [Boost-build] an implementation of msvc pdb file management for msvc.jam
From: Michael Weber (michael.weber_at_[hidden])
Date: 2009-04-20 13:57:12

> > By default, when using <debug-symbols>on/<debug-store>database (msvc compiler option /Zi) for external debug databases,
>
> This is pretty interesting. I never used "<debug-store>database" option yet I was always getting correctly named PDB files. I guess this is because when debug symbols are enabled via just "<debug-symbols>on", the compiler gets "/Z7" option. I.e. it adds debug information to the .obj file itself. Once it is done the linker is able to generate correctly named .PDB file.
>
> Is there any particular reason why you need /Zi to be used and not /Z7? Are you doing something special?

Good question - I had to review the differences, as I've been using
/Zi for so long. The /Zi option uses Microsoft's latest debug format
(Program Database) whereas /Z7 uses the older format CodeView format.
As you point out, in both cases, the linker can generate the Program
Database format (.pdb files) for the executable. So what are the
differences...

1. PDB format supports incremental linking. I have not tested whether
this requires PDB format coming out of the compiler (/Zi), or just the
linker (compile /Z7, link /PDB).

2. /Z7 is not compatible with /clr -- i.e., when compiling for a .NET
binary. You must use /Zi in order to generate debug information for a
.NET binary. This is a requirement for our project. In addition to
building a Firefox extension (and an Internet Explorer extension) in
native C++, we also wrap our C++ libraries into a .NET component using
managed C++ on Windows. We only use it for an internal tool, and until
now we build it with an MSVC project file. However, I am converting
all my C++ project files into boost.build format, and plan to convert
this tool as well. Seems like a generally useful feature, for
cross-platform projects that also package build artifacts into .NET
targets on Windows.

3. With the /ZI option (capital 'i'), it supports "edit and continue",
a feature you can use when working within the MSVC IDE in the debugger
to quickly edit / recompile / relink without stopping the debug
session. I do not use this feature personally. (I have not testing
whether it would work if you created a 'makefile' project in MSVC in
order to invoke a bjam build from a MSVC IDE project file, but I see
no reason why it would not work.)

I think better performance is the reason we switched to using /Zi on
my previous project, at another company. On that project, we compiled
a massive code base, and many server components took a very long time
to link due to the number of libraries involved. I recall that we
explicitly switched to standardizing on /Zi at some point in the
project. I forget whether this was only for developers, for the
incremental linking benefit, or whether clean builds benefit too.

In any case, since that project, I am in the habit of using /Zi. And,
since it is the "latest / presumably greatest" msvc debug format, I
think boost.build would benefit from not only enabling its use, but
helping manage the compile-time artifacts. Of course, my
implementation is tailored to my own needs, in the interests of
expediency. A more generalized set of flags to give developers full
control over how the files are named and where they go at both compile
and link time would be the 'ultimate' solution for Windows targets.
Mostly a benefit for people developing cross platform code but
spending most of their development time using Microsoft tools on a
Windows platform (no flames please! :-)

best regards,
Michael Weber