Aiding reproducibility in builds with MS Visual C++

<AdditionalOptions>%(AdditionalOptions) /d1trimfile:"$(SolutionDir)\"</AdditionalOptions>

In your .vcxproj file or a Directory.Build.props when passed to the compiler (cl.exe, ClCompile) this should trim the leading path used for __FILE__. The backslash is actually required here, because SolutionDir ends in a backslash itself, but we do not want to escape the double closing quote, i.e. the backslash in SolutionDir is essentially escaping the backslash we give, because otherwise the single backslash in the expanded version of the command line would wreak havoc.

GCC and Clang appear to have __FILE_NAME__. However, it should be noted that this expands only to the last component (i.e. past the last path separator). This may be desirable, but I find Microsoft’s idea a little more convincing in this case.

Additionally you could pass /Brepro to cl.exe and link.exe

Another good one is passing /pdbaltpath:%_PDB% to link.exe to cause it to leave out the full path to the .pdb file, i.e. only the file name itself will be recorded in the build artifact. Note, however, if you are copying around your resulting DLLs and executables, for example, and you don’t use a symbol store which you populate post-build, chances are that the debugger won’t find your debug symbols files. One way to get around this is to copy the .pdb files alongside the binaries or use a symbol store ((using the symstore tool)), as is customary.

// Oliver

PS: here’s another blog article about the subject matter, leading to even further resources.
PPS: this comment on GitHub also provides some further details, including two other options: /experimental:deterministic (to warn about problematic code) and /d1nodatetime (which, according to the comment is implied by /Brepro).

This entry was posted in C/C++, Programming, Software and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *