On Thursday, October 23, 2014 11:13:15 AM Brad King wrote: > On 10/21/2014 11:44 AM, Clinton Stimpson wrote: > > Because the design of this Bundle generator is not consistent with the > > rest of the CPack generators, you don't have this same chance, and the > > only way to do customization is to keep adding patches like yours. > > Is this something that should be refactored in CPack to address > independently of the codesign changes?
Actually, the design is intentional -- that is, it has the feature of creating the application bundle for you, which involves handling for icons, Info.plist, and now the proposed code signing. Alternatively, we have handling for icons and Info.plist in add_executable(... MACOSX_BUNDLE ...). So basically, its duplicated functionality. There are 2 approaches: 1. set(INSTALL_LIB_DIR lib) set(INSTALL_BIN_DIR bin) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo ...) target_link_libraries(foo foolib) add_executable(foo2 ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 RUNTIME DESTINATION ${INSTALL_BIN_DIR}) set(CPACK_GENERATOR Bundle) set(CPACK_BUNDLE_STARTUP_COMMAND "StartScript") include(CPack) The end result is a foo.app/Contents/MacOS/foo (renamed from StartScript) foo.app/Contents/MacOS/bin/foo foo.app/Contents/MacOS/bin/foo2 foo.app/Contents/MacOS/lib/libfoo.dylib If any other CPack generator is used (TGZ, DragNDrop, PackageMaker, etc...), the package layout will be bin/foo bin/foo2 lib/libfoo.dylib 2. set(INSTALL_LIB_DIR foo.app/Contents/MacOS) set(INSTALL_BIN_DIR foo.app/Contents/MacOS) add_library(foolib ...) install(TARGETS foolib RUNTIME DESTINATION ${INSTALL_LIB_DIR}) add_executable(foo MACOSX_BUNDLE ...) target_link_libraries(foo foolib) add_executable(foo2 MACOSX_BUNDLE ...) target_link_libraries(foo2 foolib) install(TARGETS foo foo2 BUNDLE DESTINATION . RUNTIME DESTINATION ${INSTALL_BIN_DIR}) include(CPack) The end result is a foo.app/Contents/MacOS/foo foo.app/Contents/MacOS/foo2 foo.app/Contents/MacOS/libfoo.dylib This gives consistent results with all CPack generators (TGZ, DragNDrop, PackageMaker, etc..) except for the Bundle generator. Similar to #2, CMake itself uses an interesting approach of modifying CMAKE_INSTALL_PREFIX to redirect the installation into the CMake.app bundle, without modifying the DESTINATION option to the install() commands. If the Bundle generator is changed to be made consistent with other cpack generators (which implies you lose the bundle making feature), you end up with what the DragNDrop generator is. And now there is code signing.... There is a chance that code signing will be introduced into CMake using another mechanism that works across platforms and across cpack generators. How that will interact with the propose patch, I do not know, so I do have some concern about adding this patch. So Brad, does this give you some idea of the situation? Do you have some thoughts on merging the patch? Clint -- 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://public.kitware.com/mailman/listinfo/cmake-developers