On Wed, Apr 29, 2015 at 1:52 PM, Greg Bedwell <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
