Dear Clinton and David, Thanks for your replies. I did notice the COMPONENT discrepancy on my other project, but I figured out now that I had misunderstood the first time (or at least I think so). What I wrote then was something along the lines of (which didn't work): INSTALL(TARGETS ${mtargets} BUNDLE DESTINATION . RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib COMPONENT Runtime ) What I just now realized worked was to do instead INSTALL(TARGETS ${mtargets} BUNDLE DESTINATION . COMPONENT Runtime RUNTIME DESTINATION bin COMPONENT Runtime LIBRARY DESTINATION lib COMPONENT Libraries ARCHIVE DESTINATION lib COMPONENT Libraries ) In other words, for every type of target, set the component. This now works very well for the Mad-X project. I had also done some other unnecessary complications with the COMPONENT stuff on the other project, which cluttered things and hid my real problems I think.
>>> What libs does your bundle app depend on? Are they >>> built into the app with full path names such that an tool -L analysis >>> will work without any DIRS value? Currently only X11, sometimes libgfortran (I think it depends on which gfortran version you are using?). At least for this project, otool -L solves it all. For my other project which I don't have in a public place at the moment it looks like I have a bit more problems now (it worked as well with my previous install). You might have given me a good hint right there. To both of you, thank you very much for your time and help! Best Regards, and a Merry Christmas to everyone on the list, Yngve On 21 December 2011 00:33, David Cole <david.c...@kitware.com> wrote: > Good catch, Clinton. I did not notice the COMPONENT discrepancy. > > > On Tue, Dec 20, 2011 at 6:26 PM, Clinton Stimpson <clin...@elemtech.com> > wrote: >> >> This doesn't look right: >> >> INSTALL(TARGETS ${mtargets} >> BUNDLE DESTINATION . >> RUNTIME DESTINATION bin >> LIBRARY DESTINATION lib >> ARCHIVE DESTINATION lib >> ) >> >> INSTALL(CODE " >> include(BundleUtilities) >> fixup_bundle(\"${APPS}\" \"\" \"${DIRS}\") >> " COMPONENT Runtime) >> >> The target and fixup of the target are in different components, so that can >> cause problems at cpack time depending on your generator. >> >> Clint >> >> On Tuesday, December 20, 2011 04:13:35 pm David Cole wrote: >>> You're doing this: >>> >>> set(APPS "\${CMAKE_INSTALL_PREFIX}/madx${BINARY_POSTFIX}.app") # >>> paths to executables >>> set(DIRS "") >>> >>> Then this: >>> >>> INSTALL(CODE " >>> include(BundleUtilities) >>> fixup_bundle(\"${APPS}\" \"\" \"${DIRS}\") >>> " COMPONENT Runtime) >>> >>> Which means that your install code (in cmake_install.cmake) will have >>> something like this in it: >>> >>> include(BundleUtilities) >>> fixup_bundle("${CMAKE_INSTALL_PREFIX}/madxXXX.app" "" "") >>> >>> CMAKE_INSTALL_PREFIX should evaluate to a directory underneath the >>> _CPack_Packages directory, so that should be ok. But your DIRS >>> variable is empty. What libs does your bundle app depend on? Are they >>> built into the app with full path names such that an tool -L analysis >>> will work without any DIRS value? >>> >>> Did you run something like "cpack -G DragNDrop --verbose" to see the >>> full output of the make install step, and did it seem like >>> fixup_bundle yielded any output in the --verbose stream...? >>> >>> Your code looks right, but maybe you need some DIRS for the fixup to >>> work correctly... >>> >>> >>> HTH, >>> David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake