On 13/02/2014 19:44, Bill Hoffman wrote:
HI Bill,
On 2/13/2014 2:23 PM, Bill Somerville wrote:
I would really like to know why it is going wrong with dumpbin in
package generation because using objtool is too slow!
Sounds like a PATH issue. Try getting dumpbin to work from the
command line that you are using.
GetPrerequisites.cmake doesn't expect dumpbin on the PATH, it uses
find_binary with some hard codes paths to find it and runs it with a
full absolute path.
It does try to inject the path of the found dumpbin +
'..\..\Common7\IDE' into PATH before using it. This extra PATH element
is where the DLLs that dumbin uses are located. This is where the
problem lies.
For some reason the set(ENV{PATH} ...) command is working in the cmake
install target driven BundleUtilities::fixup_bundle call to
GetPrerequisites::get_prerequisites. But when the package target is
built the same code fails to update the PATH.
Clearly CPack is doing something different (and deficient) when it
processes the install () commands from CMakeLists.txt :(
Can anyone help with how I can get CPack to behave the same a CMake for
the same CMakeLists.txt?
I would revert to my fix to force GetPrerequisites to use objdump but
not only is it slow but also it doesn't copy the prerequisites into the
package unless the package target is run twice.
-Bill
Bill.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
