[PATCH] Embed Windows version resource information into our exe and dll files

[Greg Bedwell]

New patch attached.  Apologies for the delay.  I had to work on something else temporarily but am now free to hack on compilers once more - hooray!.

For the benefit of cfe-commits who I've just added, this patch adds a VERSIONINFO resource to .exe and .dll files when we build LLVM with MSVC.  The most visible place that you can find Windows version information is by looking at the file properties in Windows Explorer under the details tab.  It's also embedded into minidump .dmp files (a subsequent change that I plan to submit will add the capability of automatically generating these files in the case of crashes on Windows).

As suggested I separated the part that fixed an issue with the Ninja builder into another patch which was committed at r232727.

I've split the CMake function from the original patch into 2 functions now.  The first just adds the resource script file to the current project if we're building with MSVC.  The second checks whether the resource script exists in the current project and sets preprocessor macros for that file containing the version information to embed if it does.  There are a couple of reasons for splitting it.  Firstly, we need to add the resource script file to the project sources before the target has been created, but in order to populate the 'OriginalFilename' field we need the target location which only exists once the target has been created.  Secondly, it means that we can call the 'set_windows_version_resource_properties' function from specific subproject CMakelists files to override the default values if necessary.

By default we're setting the FILEVERSION field with the following values from CMake:

  LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR, LLVM_VERSION_PATCH, 0

The "FileVersion" and "ProductVersion" fields which are strings get set to the value of PACKAGE_VERSION.
The "OriginalFilename" field gets set with the name of the exe or DLL file that the project creates.  Note that this means that files such as clang++.exe or clang-cl.exe will still get the string 'clang.exe' in this field as they are just copies of clang.exe.  "InternalName" as per the Microsoft documentation suggestion gets set to the filename string without the extension (so 'clang' in the above cases).  I've set 'ProductName' to 'LLVM' by default.

I'll followup with a separate clang patch very shortly that overrides the LLVM version numbers with the clang equivalent ones and sets 'ProductName' to 'clang' when building projects that come from tools/clang.  I'm happy to bikeshed on the strings that particular fields should get as long as the general approach is considered acceptable.

Thanks,
Greg


http://reviews.llvm.org/D7828

Files:
  cmake/modules/AddLLVM.cmake
  resources/windows_version_resource.rc

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D7828.24644.patch
Type: text/x-patch
Size: 8494 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150429/5a6587bf/attachment.bin>