[cmake-developers] Support of codesign

Clinton Stimpson clinton at elemtech.com
Thu Oct 23 12:21:31 EDT 2014


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




More information about the cmake-developers mailing list