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

[Aaron Ballman]

On Wed, Apr 29, 2015 at 1:52 PM, Greg Bedwell <gregbedwell at gmail.com> wrote:
> Here's a clang side patch that overrides the LLVM version numbers with their
> clang equivalents for anything from tools/clang.  I couldn't figure out how
> to put both patches in Phabricator at the same time without lumping them
> into a single patch file but I wanted them both available to provide context
> to each other.  I'm not aware of any other in-tree projects that potentially
> use their own versioning scheme.

The patch goes in the right direction, but we have a lot of other
executables that we want this for, right? Such as all the tools that
come with llvm? (I realize this is the Clang patch, but I figured this
would hit all the .exe files that would be distributed to users and
run as part of their toolchains.)

~Aaron

>
> Hopefully this explains the reason for the interface of
> set_windows_version_resource_properties on the LLVM side.  I went with
> "$CLANG_VERSION ($BACKEND_PACKAGE_STRING)" for the VERSION_STRING fields as
> it seemed to give more useful information about the origin of the build
> (especially if LLVM_APPEND_VC_REV is enabled which makes it include the SVN
> revision number) but I'm happy just to use $CLANG_VERSION only or whatever
> else is preferred.
>
> A further enhancement could be to populate the FileDescription field for any
> files that we feel would benefit (presumably user-facing files such as
> clang.exe and friends) so that it will show up in the Windows Task Manager
> when running which feels generally polite to do.  I'm happy to do this
> if/when these changes land :-).
>
> Thanks,
> Greg
>
> On 29 April 2015 at 18:22, Greg Bedwell <greg_bedwell at sn.scee.net> wrote:
>>
>> 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/
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>