gn build: Windows: use a more standard format for PDB filenames

[dmajor]

Summary

The current build was producing names like llvm-undname.exe.pdb, which looks unusual to me at least. This switches them to the more common llvm-undname.pdb style.

[dmajor]

llvm/utils/gn/build/toolchain/BUILD.gn

249

Does pdbfile need to be included in any of the above output(s) lines? (I don't know what they do.)

[thakis]

Do you care much about this? The naming here might be somewhat unconventional, but it's more flexible (consider the completely hypothetical case of a build having both "chrome.exe" and "chorme.dll" – if you call the pdb for both "chrome.dll" they'll get in each other's way, but with this scheme it works fine) and ever so slightly less code. So I weakly prefer what we currently have, but I almost never do debug builds so I don't care all that much. I'll accept this so that you can land it if you want, but I'd weakly prefer if you didn't :-)

llvm/utils/gn/build/toolchain/BUILD.gn

249

see llvm/utils/gn/gn.py help tool, section "outputs" :-P

Ninja knows that the link rule produces the outputs listed here if depend_output isn't set. Since depend_output _is_ set, I'm not sure what's in outputs matters all that much. If depend_output _wasn't_ set and pdbfile was in this list, then a build step that lists the pdb file as an input without depending on the executable() or shared_library() target that produces it would still correctly run the link to produce the pdb before running that step. But such a step should have a dep on the executable() / shared_library() for cleanliness anyhow, and the pdb is only written in debug builds, which we don't easily know if that's the case here, so I just omitted it.

[dmajor]

In D57613#1381830, @thakis wrote:

Do you care much about this? The naming here might be somewhat unconventional, but it's more flexible (consider the completely hypothetical case of a build having both "chrome.exe" and "chorme.dll" – if you call the pdb for both "chrome.dll" they'll get in each other's way, but with this scheme it works fine) and ever so slightly less code. So I weakly prefer what we currently have, but I almost never do debug builds so I don't care all that much. I'll accept this so that you can land it if you want, but I'd weakly prefer if you didn't :-)

I care about it mildly (a hair more than weakly :-P).

For better or worse this is the convention on Windows, including LLVM's cmake build and Microsoft's own published symbols, so this file doesn't seem like the right place to push for a change. If the cmake build changes its tune, I'm fine with you reverting this. :-)

llvm/utils/gn/build/toolchain/BUILD.gn

tool("alink") {
     description = "LIB {{output}}"
     outputs = [
       "{{output_dir}}/{{target_output_name}}.lib",
     ]
     default_output_dir = "{{root_out_dir}}/lib"
   }
 
   tool("solink") {
-    dllfile = "{{output_dir}}/{{target_output_name}}{{output_extension}}"
-    libfile = "$dllfile.lib"
-    command = "$link /nologo /dll {{ldflags}} /out:$dllfile /implib:$libfile {{libs}} /pdb:$dllfile.pdb {{inputs}}"
+    outprefix = "{{output_dir}}/{{target_output_name}}"
+    dllfile = "$outprefix{{output_extension}}"
+    libfile = "$outprefix.lib"
+    pdbfile = "$outprefix.pdb"
+    command = "$link /nologo /dll {{ldflags}} /out:$dllfile /implib:$libfile /pdb:$pdbfile {{libs}} {{inputs}}"
     description = "LINK $dllfile"
     link_output = libfile
     depend_output = libfile
     runtime_outputs = [ dllfile ]
     outputs = [
       dllfile,
       libfile,
     ]
     default_output_extension = ".dll"
     restat = true
 
     # Put dlls next to the executables in bin/ on Windows, since Windows
     # doesn't have a configurable rpath. This matches initialization of
     # module_dir to bin/ in AddLLVM.cmake's set_output_directory().
     default_output_dir = "{{root_out_dir}}/bin"
   }
 
   # Plugins for opt and clang and so on don't work in LLVM's Windows build
   # since the code doesn't have export annotations, but there are a few
   # standalone loadable modules used for unit-testing LLVM's dynamic library
   # loading code.
   tool("solink_module") {
-    dllfile = "{{output_dir}}/{{target_output_name}}{{output_extension}}"
-    command = "$link /nologo /dll {{ldflags}} /out:$dllfile {{libs}} /pdb:$dllfile.pdb {{inputs}}"
+    outprefix = "{{output_dir}}/{{target_output_name}}"
+    dllfile = "$outprefix{{output_extension}}"
+    pdbfile = "$outprefix.pdb"
+    command = "$link /nologo /dll {{ldflags}} /out:$dllfile /pdb:$pdbfile {{libs}} {{inputs}}"
     description = "LINK_MODULE $dllfile"
     outputs = [
       dllfile,
     ]
     runtime_outputs = outputs
     default_output_extension = ".dll"
 
     # No default_output_dir, all clients set output_dir.
   }
 
   tool("link") {
-    outfile = "{{output_dir}}/{{target_output_name}}{{output_extension}}"
-    command = "$link /nologo {{ldflags}} /out:$outfile {{libs}} /pdb:$outfile.pdb {{inputs}}"
+    outprefix = "{{output_dir}}/{{target_output_name}}"
+    outfile = "$outprefix{{output_extension}}"
+    pdbfile = "$outprefix.pdb"
+    command = "$link /nologo {{ldflags}} /out:$outfile /pdb:$pdbfile {{libs}} {{inputs}}"
     description = "LINK $outfile"
     outputs = [
       outfile,
     ]
     default_output_extension = ".exe"
 
     # Setting this allows targets to override the default executable output by
     # setting output_dir.