[PATCH] Embed Windows version resource information into our exe and dll files
aaron.ballman at gmail.com
Fri May 1 07:03:08 PDT 2015
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.)
> 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 :-).
> 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
>> 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.
>> EMAIL PREFERENCES
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
More information about the cfe-commits