On Wed, Apr 29, 2015 at 1:22 PM, 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.
> Index: cmake/modules/AddLLVM.cmake
> ===================================================================
> --- cmake/modules/AddLLVM.cmake
> +++ cmake/modules/AddLLVM.cmake
> @@ -228,6 +228,76 @@
> endif()
> endfunction()
>
> +# If on Windows and building with MSVC, add the resource script containing
> the
> +# VERSIONINFO data to the project. This embeds version resource information
> +# into the output .exe or .dll.
What about on Windows building with something like MinGW? Should we do
this then as well?
> +function(add_windows_version_resource_file OUT_VAR)
> + set(sources ${ARGN})
> + if (MSVC)
> + set(resource_file
> ${LLVM_SOURCE_DIR}/resources/windows_version_resource.rc)
> + set(sources ${sources} ${resource_file})
> + source_group("Resource Files" ${resource_file})
> + set(windows_resource_file ${resource_file} PARENT_SCOPE)
> + endif(MSVC)
> +
> + set(${OUT_VAR} ${sources} PARENT_SCOPE)
> +endfunction(add_windows_version_resource_file)
Otherwise, LGTM!
~Aaron
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
