Fixup_bundle (BundleUtilities) and GetPrerequisites error on VS2015 / cmake 3.6.1
When calling fixup_bundle in one of my builds, I get the following error
CMake Error at C:/Program Files/CMake/share/cmake-3.6/Modules/GetPrerequisites.cmake:818 (message):
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/dumpbin.exe
failed: 1181
Microsoft (R) COFF/PE Dumper Version 14.00.24213.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file api-ms-win-crt-environment-l1-1-0.dll
Prior to that, I get a lot of warnings about the inability to resolve a bunch of api-ms-win DLLs (e.g. warning: cannot resolve item 'api-ms-win-crt-environment-l1-1-0.dll').
The same build using visual studio 2010 as a generator works as expected.
I have been able to track the problem down to the GetPrerequisites module. Apparently, the dumpbin.exe in vs2015 does return those "api-ms-win" DLLs whereas the one in vs2010 does not.
Then, they are passed to the function gp_resolved_file_type (in GetPrerequisites), which does have a conditional to determine whether it is a system DLL or not (system DLLs are ignored in fixup_bundle):
if(lower MATCHES "^(api-ms-win-|${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll)")
set(is_system 1)
endif()
So while it does look like the function has a way of checking whether we are dealing with the api-ms-win DLLs, apparently that regex only matches if it is found at the beginning of the "lower" variable. But for some reason, "lower" contains the path to the .exe I called fixup_bundle on, so instead of being the name of the DLL alone, it is c:/path/to/binary/folder/api-ms-win-xxxxx.dll
Which misses the condition, and because of that, eventually dumpbin is called on the api-ms-win DLLs, but because they are not found, it fails and that is the error.
Again, works fine with VS2010 as the generator (because dumpbin has a different output).
A possible fix is to amend the regex expression to look anywhere in the string for "api-ms-win", but that wouldn't get rid of the many many warnings. I think something else may be wrong somewhere before calling gp_resolved_file_type ?