[Scons-dev] Looking for help mapping Windows pdb semantics to SCons

[Adam Gross]

I am investigating better supporting caching with SCons at VMware and am trying to see if I can teach SCons about pdb files. Sorry, this e-mail will be a bit long because the topic is quick convoluted.

Right now we do a fine job with pdb files for programs and shared libraries, because we register a separate node (e.g. "foo-debug") that is referenced by the packaging code. However, static libraries and standalone object file compilations are not handled well because of how Windows writes per-directory pdbs when we provide the /Fd flag (reference for that flag - https://docs.microsoft.com/en-us/cpp/build/reference/fd-program-database-file-name?view=vs-2019 ).

As an example, if we have the following files in a directory:

topdir\subdir\a.cpp
topdir\subdir\b.cpp

Our subdirectory-related build system would set up both a.cpp and b.cpp to compile with the parameter /Fdbuild\intdir\topdir\subdir\subdir.pdb. The crucial point here is that the compiler will write to subdir.pdb when compiling both a.cpp and b.cpp. If the resulting object files are archived into a static library, the archiver will not actually touch that .pdb file. That is, writing that subdir.pdb file is done by the compiler when building each source object.

It was tempting to then say that subdir.pdb is a SideEffect of each compilation action, but we don't want that because (1) it would prevent those files from compiling in parallel and (2) it still wouldn't allow us to support retrieving that pdb from cache. Microsoft supports compiling these in parallel because writes to the pdb go through a separate process mspdbsrv.exe, which deals with synchronization of writes to that file.

So in this case, I can't find a way to treat these pdb's. There are two real use cases here:


  1.  We eventually link the object files from the subdirectory into a static library, which is then linked with other things into the dll/exe.
  2.  We don't link them together and instead link the various obj files into the dll/exe.

For #1, I can get away with considering the subdirectory's common pdb file to be another target along with the static library. So despite the archiver not actually touching subdir.pdb, we would still say that the archive action has a target of subdir.lib and subdir.pdb (cheating a bit, but it works).

For #2, I can't find a way to track this. Ideally there would be some sort of "meta-target" construct in SCons so that the compilation action for a.cpp and b.cpp can list subdir.pdb as another target, but AFAICT that would cause SCons to complain that the same target is defined in multiple places.

Any ideas or pointers to help?

Thanks,
Adam Gross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20190524/153af4a6/attachment.html>