aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/backend/ninjabackend.py
diff options
context:
space:
mode:
authorJussi Pakkanen <jpakkane@gmail.com>2016-09-10 13:11:13 +0300
committerJussi Pakkanen <jpakkane@gmail.com>2016-09-10 13:26:37 +0300
commitc7e5e558f9b80c695907336f2150d097d9883ba4 (patch)
treeab8ef95e7294db68dcd6a8c2c11a63a8c00d6028 /mesonbuild/backend/ninjabackend.py
parenta9da6c513281bd7c213d8d3d33c78c7ceed9dfd4 (diff)
downloadmeson-c7e5e558f9b80c695907336f2150d097d9883ba4.zip
meson-c7e5e558f9b80c695907336f2150d097d9883ba4.tar.gz
meson-c7e5e558f9b80c695907336f2150d097d9883ba4.tar.bz2
More PDB explanation.
Diffstat (limited to 'mesonbuild/backend/ninjabackend.py')
-rw-r--r--mesonbuild/backend/ninjabackend.py54
1 files changed, 39 insertions, 15 deletions
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
index 1f848f3..28667b7 100644
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -1437,29 +1437,53 @@ rule FORTRAN_DEP_HACK
if compiler.id != 'msvc':
return []
# The way MSVC uses PDB files is documented exactly nowhere so
- # the following is what we have been able to decipher via reverse
- # engineering.
+ # the following is what we have been able to decipher via
+ # reverse engineering.
+ #
+ # Each object file gets the path of its PDB file written
+ # inside it. This can be either the final PDB (for, say,
+ # foo.exe) or an object pdb (for foo.obj). If the former, then
+ # each compilation step locks the pdb file for writing, which
+ # is a bottleneck and object files from one target can not be
+ # used in a different target. The latter seems to be the
+ # sensible one (and what Unix does) but there is a catch. If
+ # you try to use precompiled headers MSVC will error out
+ # because both source and pch pdbs go in the same file and
+ # they must be the same.
#
- # Each object file gets the path of its PDB file written inside it.
- # This can be either the final PDB (for, say, foo.exe) or an object
- # pdb (for foo.obj). If the former, then each compilation step locks
- # the pdb file for writing, which is a bottleneck and object files from
- # one target can not be used in a different target. The latter seems
- # to be the sensible one (and what Unix does) but there is a catch.
- # If you try to use precompiled headers MSVC will error out because
- # both source and pch pdbs go in the same file and they must be the same.
# This means:
#
# - pch files must be compiled anew for every object file (negating
# the entire point of having them in the first place)
# - when using pch, output must go to the target pdb
#
- # Since both of these are broken in some way, use the one that works
- # for each target. This unfortunately means that you can't combine
- # pch and object extraction in a single target.
+ # Since both of these are broken in some way, use the one that
+ # works for each target. This unfortunately means that you
+ # can't combine pch and object extraction in a single target.
+ #
+ # PDB files also lead to filename collisions. A target foo.exe
+ # has a corresponding foo.pdb. A shared library foo.dll _also_
+ # has pdb file called foo.pdb. So will a static library
+ # foo.lib, which clobbers both foo.pdb _and_ the dll file's
+ # export library called foo.lib (by default, currently we name
+ # them libfoo.a to avoidt this issue). You can give the files
+ # unique names such as foo_exe.pdb but VC also generates a
+ # bunch of other files which take their names from the target
+ # basename (i.e. "foo") and stomp on each other.
#
- # If you feel that the above is completely wrong and all of this is
- # actually doable, please send patches.
+ # CMake solves this problem by doing two things. First of all
+ # static libraries do not generate pdb files at
+ # all. Presumably you don't need them and VC is smart enough
+ # to look up the original data when linking (speculation, not
+ # tested). The second solution is that you can only have
+ # target named "foo" as an exe, shared lib _or_ static
+ # lib. This makes filename collisions not happen. The downside
+ # is that you can't have an executable foo that uses a shared
+ # library libfoo.so, which is a common idiom on Unix.
+ #
+ # If you feel that the above is completely wrong and all of
+ # this is actually doable, please send patches.
+
if target.has_pch():
tfilename = self.get_target_filename_abs(target)
return compiler.get_compile_debugfile_args(tfilename)