Signing individual binary and problem with PackageMaker CPack generator

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Signing individual binary and problem with PackageMaker CPack generator

Anatoly Belyaev

We use CMake

add_custom_command(TARGET POST_BUILD COMMAND codesign ...)

for signing executable files on build. It works fine, but when CPack generates package it rewrites rpath on executable files and call strip command on them. This changes the file and invalidates the signature. Is there any way in CMake to sign binary files after CPack finishes install and before actual packaging?

--
----------------------------------------
Best regards, Anatoly Belyaev


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Anatoly Belyaev

We use "PackageMaker" generator on MacOS.  But i don't think it is CPack specific tool does call strip command.  The code for RPATH rewrite and strip cmd is located in cmake_install.cmake. As i understand CPack calls make install to tmp dir and then creates package.

Having different RPATH for build tree is useful. May be there is a way to call sign tool in the install stage? But reading the doc to CMake install command, doesn't help me find solution for this.

----------------------------------------
Best regards, Anatoly Belyaev


On 22.10.2018 11:55, Eric Noulard wrote:


Le lun. 22 oct. 2018 à 10:21, Anatoly Belyaev <[hidden email]> a écrit :

We use CMake

add_custom_command(TARGET POST_BUILD COMMAND codesign ...)

for signing executable files on build. It works fine, but when CPack generates package it rewrites rpath on executable files and call strip command on them. This changes the file and invalidates the signature. Is there any way in CMake to sign binary files after CPack finishes install and before actual packaging?

As you discovered CPack runs at a different moment than CMake (see: https://github.com/dev-cafe/cmake-cookbook/blob/master/figures/cmake-times/cmake-times.jpg)

RPATH is rewritten because you may have different build and install RPATH.

Concerning the strip part I'm not sure CPack does that. May be the CPack generator specific tool does it?
I bet there is no generic way to that without extending CPack or the particular generator ou are using.
What CPack generator(s) do you use?

--
Eric


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Eric Noulard


Le lun. 22 oct. 2018 à 11:56, Anatoly Belyaev <[hidden email]> a écrit :

We use "PackageMaker" generator on MacOS.  But i don't think it is CPack specific tool does call strip command.  The code for RPATH rewrite and strip cmd is located in cmake_install.cmake. As i understand CPack calls make install to tmp dir and then creates package.


Sorry I've just realized it was in the title of your message.
I wasn't aware that stripping was done during install.
 

Having different RPATH for build tree is useful. May be there is a way to call sign tool in the install stage? But reading the doc to CMake install command, doesn't help me find solution for this.


Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

--
Eric

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Craig Scott-3


On Tue, Oct 23, 2018 at 12:32 AM Eric Noulard <[hidden email]> wrote:


Le lun. 22 oct. 2018 à 11:56, Anatoly Belyaev <[hidden email]> a écrit :

We use "PackageMaker" generator on MacOS.  But i don't think it is CPack specific tool does call strip command.  The code for RPATH rewrite and strip cmd is located in cmake_install.cmake. As i understand CPack calls make install to tmp dir and then creates package.

Unrelated to your question, but PackageMaker is deprecated (by Apple). Recent macOS releases don't even have it. You may want to look into productbuild instead.

 

Sorry I've just realized it was in the title of your message.
I wasn't aware that stripping was done during install.
 

Having different RPATH for build tree is useful. May be there is a way to call sign tool in the install stage? But reading the doc to CMake install command, doesn't help me find solution for this.


Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it).

--
Craig Scott
Melbourne, Australia


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Eric Noulard
Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

I wasn't sure of that. 

So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?


Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it).

--
Craig Scott
Melbourne, Australia


--
Eric

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Craig Scott-3


On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard <[hidden email]> wrote:
Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

I wasn't sure of that. 

So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?

My understanding is that install() commands are generally processed in the order in which they appear in the directory scope. It is unspecified how the order between directory scopes behaves, although this merge request (now merged to master) makes things much more predictable.

I missed the earlier detail about when stripping occurred in relation to installing. From what I can see, I think the stripping happens right after the executable is copied/installed. Have a look at the generated cmake_install.cmake file for one of your builds and search for CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own install(CODE) or install(SCRIPT) calls after you've done the install(TARGETS) calls, I would expect them to come after the stripping, but I haven't tested this.


--
Craig Scott
Melbourne, Australia


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Eric Noulard


Le mar. 23 oct. 2018 à 12:06, Craig Scott <[hidden email]> a écrit :


On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard <[hidden email]> wrote:
Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

I wasn't sure of that. 

So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?

My understanding is that install() commands are generally processed in the order in which they appear in the directory scope. It is unspecified how the order between directory scopes behaves, although this merge request (now merged to master) makes things much more predictable.

I missed the earlier detail about when stripping occurred in relation to installing. From what I can see, I think the stripping happens right after the executable is copied/installed. Have a look at the generated cmake_install.cmake file for one of your builds and search for CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own install(CODE) or install(SCRIPT) calls after you've done the install(TARGETS) calls, I would expect them to come after the stripping, but I haven't tested this.

I'll have a look, not that I need it but I'd like to know.
Thank you Craig.

--
Eric

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Anatoly Belyaev

I tried example like this

set(test_SRC main.cpp)
install(CODE "MESSAGE(\"CODE1\")")
add_executable(test ${test_SRC})
install(TARGETS test DESTINATION ${CMAKE_INSTALL_BINDIR})
install(CODE "MESSAGE(\"CODE2\")")

Then i checked cmake_install.cmake and "CODE1" cmd will be executed before strip command and "CODE2" will be executed after strip command.  So I think that this is the good place to invoke signing tool for release builds. Probably you should have two places with signing if you want to have signed binary in build tree and install tree. One in add_custom_command and one in install(CODE ... ). But it's not a big problem.

----------------------------------------
Best regards, Anatoly Belyaev

On 23.10.2018 13:33, Eric Noulard wrote:


Le mar. 23 oct. 2018 à 12:06, Craig Scott <[hidden email]> a écrit :


On Tue, Oct 23, 2018 at 4:43 PM Eric Noulard <[hidden email]> wrote:
Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

I wasn't sure of that. 

So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?

My understanding is that install() commands are generally processed in the order in which they appear in the directory scope. It is unspecified how the order between directory scopes behaves, although this merge request (now merged to master) makes things much more predictable.

I missed the earlier detail about when stripping occurred in relation to installing. From what I can see, I think the stripping happens right after the executable is copied/installed. Have a look at the generated cmake_install.cmake file for one of your builds and search for CMAKE_INSTALL_DO_STRIP to see how things get processed. If you add your own install(CODE) or install(SCRIPT) calls after you've done the install(TARGETS) calls, I would expect them to come after the stripping, but I haven't tested this.

I'll have a look, not that I need it but I'd like to know.
Thank you Craig.

--
Eric


--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Elvis Stansvik
In reply to this post by Eric Noulard
Just going to jump in here and show how we did it (on the bus with just my phone so will be a bit terse):

packaging/InstallWindowsDeps.cmake:

include(BundleUtilities)

# Dependant executables/libraries
set(INSIGHT_ARTIFACTS
    "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
    "${CMAKE_INSTALL_PREFIX}/insightmodel.dll"
    "${CMAKE_INSTALL_PREFIX}/insightview.dll"
)

# Install the HDF5 Blosc compression plugin
find_path(H5ZBLOSC_DLL_PATH NAMES H5Zblosc.dll)
file(INSTALL
    DESTINATION "${CMAKE_INSTALL_PREFIX}"
    TYPE SHARED_LIBRARY
    OPTIONAL
    FILES "${H5ZBLOSC_DLL_PATH}/H5Zblosc.dll")

# Install fontconfig configuration
#
# Note: This assumes the layout used by [1], where the fonts
#       directory is two levels up from the bin/x64 directory
#       where the DLL is.
#
# [1] https://github.com/ShiftMediaProject/fontconfig
find_path(FONTCONFIG_DLL_PATH NAMES fontconfig.dll)
set(FONTCONFIG_FONTS_DIR "${FONTCONFIG_DLL_PATH}/../../fonts")
file(INSTALL "${FONTCONFIG_FONTS_DIR}" DESTINATION "${CMAKE_INSTALL_PREFIX}")

# Run windeployqt to install Qt libraries, plugins et.c.
execute_process(COMMAND windeployqt --no-translations --no-compiler-runtime --no-opengl-sw ${INSIGHT_ARTIFACTS})

# Run fixup_bundle(..) to bring in everything else.
fixup_bundle(
    "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
    "${CMAKE_INSTALL_PREFIX}/H5Zblosc.dll"
    ""
)

set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")

if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
    # Sign all executables/libraries
    file(GLOB_RECURSE FILES_TO_SIGN
        "${CMAKE_INSTALL_PREFIX}/*.exe"
        "${CMAKE_INSTALL_PREFIX}/*.dll"
    )

    separate_arguments(CODE_SIGNING_COMMAND WINDOWS_COMMAND "${CODE_SIGNING_COMMAND}")

    foreach(FILE_TO_SIGN ${FILES_TO_SIGN})
        execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${FILE_TO_SIGN}")
    endforeach()
endif()

packaging/Installmacosdeps.cmake:

include(BundleUtilities)

# Install the HDF5 Blosc compression plugin
find_path(H5ZBLOSC_DYLIB_PATH NAMES libH5Zblosc.dylib)
file(INSTALL
    DESTINATION "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS"
    TYPE SHARED_LIBRARY
    OPTIONAL
    FILES "${H5ZBLOSC_DYLIB_PATH}/libH5Zblosc.dylib")

# We use PATH as the list of extra search dirs for macdeployqt/fixup_bundle
string(REPLACE ":" ";" INSIGHT_LIBRARY_SEARCH_DIRS "$ENV{PATH}")

# Run macdeployqt to install Qt libraries, plugins et.c.
string(REGEX REPLACE "([^;]+)" "-libpath=\\1" _macdeployqt_flags "${INSIGHT_LIBRARY_SEARCH_DIRS}")
execute_process(COMMAND macdeployqt ${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app ${_macdeployqt_flags} -verbose=3)

# Gather list of Qt plugins
file(GLOB_RECURSE _qtplugins "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/PlugIns/*.dylib")

# Run fixup_bundle(..)
fixup_bundle(
    "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app"
    "${_qtplugins};${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS/libH5Zblosc.dylib"
    "${INSIGHT_LIBRARY_SEARCH_DIRS}"
)

# Despite what the documentation for macdeployqt says, it _does_ install
# non-Qt dependencies. It installs plain dylibs into Contents/Frameworks.
# This is a problem, because fixup_bundle(..), which we used above, will
# install the same libraries, but into Contents/MacOS. We thus remove the
# dylibs installed by macdeployqt, to avoid duplication.
file(GLOB _macdeployqt_dylibs "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/Frameworks/*.dylib")
file(REMOVE ${_macdeployqt_dylibs})

set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")

if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
    separate_arguments(CODE_SIGNING_COMMAND UNIX_COMMAND "${CODE_SIGNING_COMMAND}")

    # Sign the entire application bundle.
    #
    # Note that we assume here that the code signing command in
    # ${CODE_SIGNING_COMMAND} is capable of recursive signing of
    # an macOS application bundle (e.g. `codesign --deep ..`).
    execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app")
endif()

And then:

configure_file(CPackOptions.cmake.in "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}" @ONLY)

if(WIN32)
    configure_file(InstallWindowsDeps.cmake.in
        "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake" @ONLY)
    install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake")
    set(CPACK_GENERATOR "ZIP;WIX")
elseif(APPLE)
    configure_file(InstallMacOSDeps.cmake.in
        "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake" @ONLY)
    install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake")
    set(CPACK_GENERATOR "DragNDrop")
else()
    set(CPACK_GENERATOR "TGZ")
endif()

# General CPack options
set(CPACK_PACKAGE_NAME "${INSIGHT_CPACK_PACKAGE_NAME}")
set(CPACK_PACKAGE_VENDOR "${INSIGHT_CPACK_PACKAGE_VENDOR}")
set(CPACK_PACKAGE_VERSION_MAJOR "${INSIGHT_CPACK_PACKAGE_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${INSIGHT_CPACK_PACKAGE_VERSION_MINOR}")
set(CPACK_PACKAGE_VERSION_PATCH "${INSIGHT_CPACK_PACKAGE_VERSION_PATCH}")
set(CPACK_PACKAGE_VERSION "${INSIGHT_CPACK_PACKAGE_VERSION}")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "${INSIGHT_CPACK_PACKAGE_INSTALL_DIRECTORY}")
set(CPACK_PACKAGE_EXECUTABLES "${INSIGHT_CPACK_PACKAGE_EXECUTABLES}")
set(CPACK_CREATE_DESKTOP_LINKS "${INSIGHT_CPACK_CREATE_DESKTOP_LINKS}")
set(CPACK_WIX_UPGRADE_GUID "${INSIGHT_CPACK_WIX_UPGRADE_GUID}")
set(CPACK_WIX_UI_BANNER "${INSIGHT_CPACK_WIX_UI_BANNER}")
set(CPACK_WIX_UI_DIALOG "${INSIGHT_CPACK_WIX_UI_DIALOG}")
set(CPACK_WIX_LICENSE_RTF "${INSIGHT_CPACK_WIX_LICENSE_RTF}")
set(CPACK_WIX_PRODUCT_ICON "${INSIGHT_CPACK_WIX_PRODUCT_ICON}")
set(CPACK_WIX_PATCH_FILE "${INSIGHT_CPACK_WIX_PATCH_FILE}")
set(CPACK_DMG_BACKGROUND_IMAGE "${INSIGHT_CPACK_DMG_BACKGROUND_IMAGE}")
set(CPACK_DMG_DS_STORE_SETUP_SCRIPT "${INSIGHT_CPACK_DMG_DS_STORE_SETUP_SCRIPT}")
set(CPACK_PROJECT_CONFIG_FILE "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}")

include(CPack)

Sorry for giving you the full paste, but as you can see we're using the install(SCRIPT) approach. The scrips are generated using configure_file so we can use generator expressions.

Might not be the prettiest but has worked for us.

PS sorry for the formatting DS
Cheers,
Elvis 

Den tis 23 okt. 2018 07:43Eric Noulard <[hidden email]> skrev:
Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :

Yes I agree that having build rpath is useful.
I am not aware of any mechanism that enable calling some tool during CPack's install step.
Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.

May be some Mac user may shed some more light on this.

You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.

I wasn't sure of that. 

So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?


Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it).

--
Craig Scott
Melbourne, Australia


--
Eric
--

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:
https://cmake.org/mailman/listinfo/cmake

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Elvis Stansvik
Den tis 23 okt. 2018 kl 18:26 skrev Elvis Stansvik
<[hidden email]>:

>
> Just going to jump in here and show how we did it (on the bus with just my phone so will be a bit terse):
>
> packaging/InstallWindowsDeps.cmake:
>
> include(BundleUtilities)
>
> # Dependant executables/libraries
> set(INSIGHT_ARTIFACTS
>     "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
>     "${CMAKE_INSTALL_PREFIX}/insightmodel.dll"
>     "${CMAKE_INSTALL_PREFIX}/insightview.dll"
> )
>
> # Install the HDF5 Blosc compression plugin
> find_path(H5ZBLOSC_DLL_PATH NAMES H5Zblosc.dll)
> file(INSTALL
>     DESTINATION "${CMAKE_INSTALL_PREFIX}"
>     TYPE SHARED_LIBRARY
>     OPTIONAL
>     FILES "${H5ZBLOSC_DLL_PATH}/H5Zblosc.dll")
>
> # Install fontconfig configuration
> #
> # Note: This assumes the layout used by [1], where the fonts
> #       directory is two levels up from the bin/x64 directory
> #       where the DLL is.
> #
> # [1] https://github.com/ShiftMediaProject/fontconfig
> find_path(FONTCONFIG_DLL_PATH NAMES fontconfig.dll)
> set(FONTCONFIG_FONTS_DIR "${FONTCONFIG_DLL_PATH}/../../fonts")
> file(INSTALL "${FONTCONFIG_FONTS_DIR}" DESTINATION "${CMAKE_INSTALL_PREFIX}")
>
> # Run windeployqt to install Qt libraries, plugins et.c.
> execute_process(COMMAND windeployqt --no-translations --no-compiler-runtime --no-opengl-sw ${INSIGHT_ARTIFACTS})
>
> # Run fixup_bundle(..) to bring in everything else.
> fixup_bundle(
>     "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
>     "${CMAKE_INSTALL_PREFIX}/H5Zblosc.dll"
>     ""
> )
>
> set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")
>
> if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
>     # Sign all executables/libraries
>     file(GLOB_RECURSE FILES_TO_SIGN
>         "${CMAKE_INSTALL_PREFIX}/*.exe"
>         "${CMAKE_INSTALL_PREFIX}/*.dll"
>     )
>
>     separate_arguments(CODE_SIGNING_COMMAND WINDOWS_COMMAND "${CODE_SIGNING_COMMAND}")
>
>     foreach(FILE_TO_SIGN ${FILES_TO_SIGN})
>         execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${FILE_TO_SIGN}")
>     endforeach()
> endif()
>
>
> packaging/Installmacosdeps.cmake:
>
>
> include(BundleUtilities)
>
> # Install the HDF5 Blosc compression plugin
> find_path(H5ZBLOSC_DYLIB_PATH NAMES libH5Zblosc.dylib)
> file(INSTALL
>     DESTINATION "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS"
>     TYPE SHARED_LIBRARY
>     OPTIONAL
>     FILES "${H5ZBLOSC_DYLIB_PATH}/libH5Zblosc.dylib")
>
> # We use PATH as the list of extra search dirs for macdeployqt/fixup_bundle
> string(REPLACE ":" ";" INSIGHT_LIBRARY_SEARCH_DIRS "$ENV{PATH}")
>
> # Run macdeployqt to install Qt libraries, plugins et.c.
> string(REGEX REPLACE "([^;]+)" "-libpath=\\1" _macdeployqt_flags "${INSIGHT_LIBRARY_SEARCH_DIRS}")
> execute_process(COMMAND macdeployqt ${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app ${_macdeployqt_flags} -verbose=3)
>
> # Gather list of Qt plugins
> file(GLOB_RECURSE _qtplugins "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/PlugIns/*.dylib")
>
> # Run fixup_bundle(..)
> fixup_bundle(
>     "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app"
>     "${_qtplugins};${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS/libH5Zblosc.dylib"
>     "${INSIGHT_LIBRARY_SEARCH_DIRS}"
> )
>
> # Despite what the documentation for macdeployqt says, it _does_ install
> # non-Qt dependencies. It installs plain dylibs into Contents/Frameworks.
> # This is a problem, because fixup_bundle(..), which we used above, will
> # install the same libraries, but into Contents/MacOS. We thus remove the
> # dylibs installed by macdeployqt, to avoid duplication.
> file(GLOB _macdeployqt_dylibs "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/Frameworks/*.dylib")
> file(REMOVE ${_macdeployqt_dylibs})
>
> set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")
>
> if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
>     separate_arguments(CODE_SIGNING_COMMAND UNIX_COMMAND "${CODE_SIGNING_COMMAND}")
>
>     # Sign the entire application bundle.
>     #
>     # Note that we assume here that the code signing command in
>     # ${CODE_SIGNING_COMMAND} is capable of recursive signing of
>     # an macOS application bundle (e.g. `codesign --deep ..`).
>     execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app")
> endif()
>
>
> And then:
>
>
> configure_file(CPackOptions.cmake.in "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}" @ONLY)
>
> if(WIN32)
>     configure_file(InstallWindowsDeps.cmake.in
>         "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake" @ONLY)
>     install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake")
>     set(CPACK_GENERATOR "ZIP;WIX")
> elseif(APPLE)
>     configure_file(InstallMacOSDeps.cmake.in
>         "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake" @ONLY)
>     install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake")
>     set(CPACK_GENERATOR "DragNDrop")
> else()
>     set(CPACK_GENERATOR "TGZ")
> endif()
>
> # General CPack options
> set(CPACK_PACKAGE_NAME "${INSIGHT_CPACK_PACKAGE_NAME}")
> set(CPACK_PACKAGE_VENDOR "${INSIGHT_CPACK_PACKAGE_VENDOR}")
> set(CPACK_PACKAGE_VERSION_MAJOR "${INSIGHT_CPACK_PACKAGE_VERSION_MAJOR}")
> set(CPACK_PACKAGE_VERSION_MINOR "${INSIGHT_CPACK_PACKAGE_VERSION_MINOR}")
> set(CPACK_PACKAGE_VERSION_PATCH "${INSIGHT_CPACK_PACKAGE_VERSION_PATCH}")
> set(CPACK_PACKAGE_VERSION "${INSIGHT_CPACK_PACKAGE_VERSION}")
> set(CPACK_PACKAGE_INSTALL_DIRECTORY "${INSIGHT_CPACK_PACKAGE_INSTALL_DIRECTORY}")
> set(CPACK_PACKAGE_EXECUTABLES "${INSIGHT_CPACK_PACKAGE_EXECUTABLES}")
> set(CPACK_CREATE_DESKTOP_LINKS "${INSIGHT_CPACK_CREATE_DESKTOP_LINKS}")
> set(CPACK_WIX_UPGRADE_GUID "${INSIGHT_CPACK_WIX_UPGRADE_GUID}")
> set(CPACK_WIX_UI_BANNER "${INSIGHT_CPACK_WIX_UI_BANNER}")
> set(CPACK_WIX_UI_DIALOG "${INSIGHT_CPACK_WIX_UI_DIALOG}")
> set(CPACK_WIX_LICENSE_RTF "${INSIGHT_CPACK_WIX_LICENSE_RTF}")
> set(CPACK_WIX_PRODUCT_ICON "${INSIGHT_CPACK_WIX_PRODUCT_ICON}")
> set(CPACK_WIX_PATCH_FILE "${INSIGHT_CPACK_WIX_PATCH_FILE}")
> set(CPACK_DMG_BACKGROUND_IMAGE "${INSIGHT_CPACK_DMG_BACKGROUND_IMAGE}")
> set(CPACK_DMG_DS_STORE_SETUP_SCRIPT "${INSIGHT_CPACK_DMG_DS_STORE_SETUP_SCRIPT}")
> set(CPACK_PROJECT_CONFIG_FILE "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}")
>
> include(CPack)

Alright, now home at my keyboard so can explain a little more. This
last snippet was an excerpt from

    packaging/CMakeLists.txt

and then in our top-level CMakeLists.txt we do:

    add_subdirectory(packaging)

The snippets above contained a lot of irrelevant stuff, sorry about
that, but hope you can make out the bits related to signing.

Another thing related to packaging/deployment we have is:

if(WIN32)
    add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+

    set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION "${INSIGHT_BINDIR}")
    set(CMAKE_INSTALL_UCRT_LIBRARIES ON)
    include(InstallRequiredSystemLibraries)
endif()

The signing stuff in the snippets above are only for the installed
artifacts. The final .msi installer and .dmg bundles are signed by our
CI system, so done at another level (not CMake).

Elvis

>
>
> Sorry for giving you the full paste, but as you can see we're using the install(SCRIPT) approach. The scrips are generated using configure_file so we can use generator expressions.
>
>
> Might not be the prettiest but has worked for us.
>
>
> PS sorry for the formatting DS
>
> Cheers,
>
> Elvis
>
>
> Den tis 23 okt. 2018 07:43Eric Noulard <[hidden email]> skrev:
>>
>> Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :
>>>>
>>>>
>>>> Yes I agree that having build rpath is useful.
>>>> I am not aware of any mechanism that enable calling some tool during CPack's install step.
>>>> Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.
>>>>
>>>> May be some Mac user may shed some more light on this.
>>>
>>>
>>> You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.
>>
>>
>> I wasn't sure of that.
>>
>> So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
>> The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
>> Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?
>>
>>
>>> Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it).
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> https://crascit.com
>>>
>>> New book released: Professional CMake: A Practical Guide
>>
>>
>> --
>> Eric
>> --
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Signing individual binary and problem with PackageMaker CPack generator

Elvis Stansvik
Den tis 23 okt. 2018 kl 18:46 skrev Elvis Stansvik
<[hidden email]>:

>
> Den tis 23 okt. 2018 kl 18:26 skrev Elvis Stansvik
> <[hidden email]>:
> >
> > Just going to jump in here and show how we did it (on the bus with just my phone so will be a bit terse):
> >
> > packaging/InstallWindowsDeps.cmake:
> >
> > include(BundleUtilities)
> >
> > # Dependant executables/libraries
> > set(INSIGHT_ARTIFACTS
> >     "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
> >     "${CMAKE_INSTALL_PREFIX}/insightmodel.dll"
> >     "${CMAKE_INSTALL_PREFIX}/insightview.dll"
> > )
> >
> > # Install the HDF5 Blosc compression plugin
> > find_path(H5ZBLOSC_DLL_PATH NAMES H5Zblosc.dll)
> > file(INSTALL
> >     DESTINATION "${CMAKE_INSTALL_PREFIX}"
> >     TYPE SHARED_LIBRARY
> >     OPTIONAL
> >     FILES "${H5ZBLOSC_DLL_PATH}/H5Zblosc.dll")
> >
> > # Install fontconfig configuration
> > #
> > # Note: This assumes the layout used by [1], where the fonts
> > #       directory is two levels up from the bin/x64 directory
> > #       where the DLL is.
> > #
> > # [1] https://github.com/ShiftMediaProject/fontconfig
> > find_path(FONTCONFIG_DLL_PATH NAMES fontconfig.dll)
> > set(FONTCONFIG_FONTS_DIR "${FONTCONFIG_DLL_PATH}/../../fonts")
> > file(INSTALL "${FONTCONFIG_FONTS_DIR}" DESTINATION "${CMAKE_INSTALL_PREFIX}")
> >
> > # Run windeployqt to install Qt libraries, plugins et.c.
> > execute_process(COMMAND windeployqt --no-translations --no-compiler-runtime --no-opengl-sw ${INSIGHT_ARTIFACTS})
> >
> > # Run fixup_bundle(..) to bring in everything else.
> > fixup_bundle(
> >     "${CMAKE_INSTALL_PREFIX}/orexplore-insight.exe"
> >     "${CMAKE_INSTALL_PREFIX}/H5Zblosc.dll"
> >     ""
> > )
> >
> > set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")
> >
> > if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
> >     # Sign all executables/libraries
> >     file(GLOB_RECURSE FILES_TO_SIGN
> >         "${CMAKE_INSTALL_PREFIX}/*.exe"
> >         "${CMAKE_INSTALL_PREFIX}/*.dll"
> >     )
> >
> >     separate_arguments(CODE_SIGNING_COMMAND WINDOWS_COMMAND "${CODE_SIGNING_COMMAND}")
> >
> >     foreach(FILE_TO_SIGN ${FILES_TO_SIGN})
> >         execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${FILE_TO_SIGN}")
> >     endforeach()
> > endif()
> >
> >
> > packaging/Installmacosdeps.cmake:
> >
> >
> > include(BundleUtilities)
> >
> > # Install the HDF5 Blosc compression plugin
> > find_path(H5ZBLOSC_DYLIB_PATH NAMES libH5Zblosc.dylib)
> > file(INSTALL
> >     DESTINATION "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS"
> >     TYPE SHARED_LIBRARY
> >     OPTIONAL
> >     FILES "${H5ZBLOSC_DYLIB_PATH}/libH5Zblosc.dylib")
> >
> > # We use PATH as the list of extra search dirs for macdeployqt/fixup_bundle
> > string(REPLACE ":" ";" INSIGHT_LIBRARY_SEARCH_DIRS "$ENV{PATH}")
> >
> > # Run macdeployqt to install Qt libraries, plugins et.c.
> > string(REGEX REPLACE "([^;]+)" "-libpath=\\1" _macdeployqt_flags "${INSIGHT_LIBRARY_SEARCH_DIRS}")
> > execute_process(COMMAND macdeployqt ${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app ${_macdeployqt_flags} -verbose=3)
> >
> > # Gather list of Qt plugins
> > file(GLOB_RECURSE _qtplugins "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/PlugIns/*.dylib")
> >
> > # Run fixup_bundle(..)
> > fixup_bundle(
> >     "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app"
> >     "${_qtplugins};${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/MacOS/libH5Zblosc.dylib"
> >     "${INSIGHT_LIBRARY_SEARCH_DIRS}"
> > )
> >
> > # Despite what the documentation for macdeployqt says, it _does_ install
> > # non-Qt dependencies. It installs plain dylibs into Contents/Frameworks.
> > # This is a problem, because fixup_bundle(..), which we used above, will
> > # install the same libraries, but into Contents/MacOS. We thus remove the
> > # dylibs installed by macdeployqt, to avoid duplication.
> > file(GLOB _macdeployqt_dylibs "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app/Contents/Frameworks/*.dylib")
> > file(REMOVE ${_macdeployqt_dylibs})
> >
> > set(CODE_SIGNING_COMMAND "@INSIGHT_CODE_SIGNING_COMMAND@")
> >
> > if(NOT "${CODE_SIGNING_COMMAND}" STREQUAL "")
> >     separate_arguments(CODE_SIGNING_COMMAND UNIX_COMMAND "${CODE_SIGNING_COMMAND}")
> >
> >     # Sign the entire application bundle.
> >     #
> >     # Note that we assume here that the code signing command in
> >     # ${CODE_SIGNING_COMMAND} is capable of recursive signing of
> >     # an macOS application bundle (e.g. `codesign --deep ..`).
> >     execute_process(COMMAND ${CODE_SIGNING_COMMAND} "${CMAKE_INSTALL_PREFIX}/@INSIGHT_MACOSX_BUNDLE_BUNDLE_NAME@.app")
> > endif()
> >
> >
> > And then:
> >
> >
> > configure_file(CPackOptions.cmake.in "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}" @ONLY)
> >
> > if(WIN32)
> >     configure_file(InstallWindowsDeps.cmake.in
> >         "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake" @ONLY)
> >     install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallWindowsDeps.cmake")
> >     set(CPACK_GENERATOR "ZIP;WIX")
> > elseif(APPLE)
> >     configure_file(InstallMacOSDeps.cmake.in
> >         "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake" @ONLY)
> >     install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/InstallMacOSDeps.cmake")
> >     set(CPACK_GENERATOR "DragNDrop")
> > else()
> >     set(CPACK_GENERATOR "TGZ")
> > endif()
> >
> > # General CPack options
> > set(CPACK_PACKAGE_NAME "${INSIGHT_CPACK_PACKAGE_NAME}")
> > set(CPACK_PACKAGE_VENDOR "${INSIGHT_CPACK_PACKAGE_VENDOR}")
> > set(CPACK_PACKAGE_VERSION_MAJOR "${INSIGHT_CPACK_PACKAGE_VERSION_MAJOR}")
> > set(CPACK_PACKAGE_VERSION_MINOR "${INSIGHT_CPACK_PACKAGE_VERSION_MINOR}")
> > set(CPACK_PACKAGE_VERSION_PATCH "${INSIGHT_CPACK_PACKAGE_VERSION_PATCH}")
> > set(CPACK_PACKAGE_VERSION "${INSIGHT_CPACK_PACKAGE_VERSION}")
> > set(CPACK_PACKAGE_INSTALL_DIRECTORY "${INSIGHT_CPACK_PACKAGE_INSTALL_DIRECTORY}")
> > set(CPACK_PACKAGE_EXECUTABLES "${INSIGHT_CPACK_PACKAGE_EXECUTABLES}")
> > set(CPACK_CREATE_DESKTOP_LINKS "${INSIGHT_CPACK_CREATE_DESKTOP_LINKS}")
> > set(CPACK_WIX_UPGRADE_GUID "${INSIGHT_CPACK_WIX_UPGRADE_GUID}")
> > set(CPACK_WIX_UI_BANNER "${INSIGHT_CPACK_WIX_UI_BANNER}")
> > set(CPACK_WIX_UI_DIALOG "${INSIGHT_CPACK_WIX_UI_DIALOG}")
> > set(CPACK_WIX_LICENSE_RTF "${INSIGHT_CPACK_WIX_LICENSE_RTF}")
> > set(CPACK_WIX_PRODUCT_ICON "${INSIGHT_CPACK_WIX_PRODUCT_ICON}")
> > set(CPACK_WIX_PATCH_FILE "${INSIGHT_CPACK_WIX_PATCH_FILE}")
> > set(CPACK_DMG_BACKGROUND_IMAGE "${INSIGHT_CPACK_DMG_BACKGROUND_IMAGE}")
> > set(CPACK_DMG_DS_STORE_SETUP_SCRIPT "${INSIGHT_CPACK_DMG_DS_STORE_SETUP_SCRIPT}")
> > set(CPACK_PROJECT_CONFIG_FILE "${INSIGHT_CPACK_PROJECT_CONFIG_FILE}")
> >
> > include(CPack)
>
> Alright, now home at my keyboard so can explain a little more. This
> last snippet was an excerpt from
>
>     packaging/CMakeLists.txt
>
> and then in our top-level CMakeLists.txt we do:
>
>     add_subdirectory(packaging)
>
> The snippets above contained a lot of irrelevant stuff, sorry about
> that, but hope you can make out the bits related to signing.
>
> Another thing related to packaging/deployment we have is:
>
> if(WIN32)
>     add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+
>
>     set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION "${INSIGHT_BINDIR}")
>     set(CMAKE_INSTALL_UCRT_LIBRARIES ON)
>     include(InstallRequiredSystemLibraries)
> endif()
>
> The signing stuff in the snippets above are only for the installed
> artifacts. The final .msi installer and .dmg bundles are signed by our

s/dmg bundle/dmg disk image/

Elvis

> CI system, so done at another level (not CMake).
>
> Elvis
>
> >
> >
> > Sorry for giving you the full paste, but as you can see we're using the install(SCRIPT) approach. The scrips are generated using configure_file so we can use generator expressions.
> >
> >
> > Might not be the prettiest but has worked for us.
> >
> >
> > PS sorry for the formatting DS
> >
> > Cheers,
> >
> > Elvis
> >
> >
> > Den tis 23 okt. 2018 07:43Eric Noulard <[hidden email]> skrev:
> >>
> >> Le lun. 22 oct. 2018 à 23:05, Craig Scott <[hidden email]> a écrit :
> >>>>
> >>>>
> >>>> Yes I agree that having build rpath is useful.
> >>>> I am not aware of any mechanism that enable calling some tool during CPack's install step.
> >>>> Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.
> >>>>
> >>>> May be some Mac user may shed some more light on this.
> >>>
> >>>
> >>> You should be able to do this using install(SCRIPT) or install(CODE), invoking the code signing through execute_process() as part of that script/code.
> >>
> >>
> >> I wasn't sure of that.
> >>
> >> So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?
> >> The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?
> >> Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?
> >>
> >>
> >>> Taking a step back though, I don't know what your package contains, but if you're creating an app bundle, then you don't need CPack at all. An app bundle is already self contained and you should be able to get it to build with install RPATH, at which point it should find everything it needs. An advantage of building with install RPATH is that you can also make use of the XCODE_ATTRIBUTE target property support to set up the code signing and have Xcode/xcodebuild drive the whole code signing process for you. It's likely to be easier that way and is more compatible with tools like Fastlane, if you end up heading in that direction. But if you have embedded frameworks, then yeah, you probably end up having to do things manually yourself (CMake doesn't yet handle those well and has no direct support for it).
> >>>
> >>> --
> >>> Craig Scott
> >>> Melbourne, Australia
> >>> https://crascit.com
> >>>
> >>> New book released: Professional CMake: A Practical Guide
> >>
> >>
> >> --
> >> Eric
> >> --
> >>
> >> 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:
> >> https://cmake.org/mailman/listinfo/cmake
--

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:
https://cmake.org/mailman/listinfo/cmake