<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Le lun. 22 oct. 2018 à 23:05, Craig Scott <<a href="mailto:craig.scott@crascit.com">craig.scott@crascit.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Yes I agree that having build rpath is useful.</div><div>I am not aware of any mechanism that enable calling some tool during CPack's install step.</div><div>Moreover I don't use MacOS at all so I don't have any experience with PackageMaker.</div><div><br></div><div>May be some Mac user may shed some more light on this.</div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>I wasn't sure of that. </div><div><br></div><div>So just to be clear  do we know for sure that install(SCRIPT) install(CODE) will run after the CMake builtin-generated install scripts?</div><div>The builtin generated install script for target includes stripping, so for signing to work as expect we should be sure of the execution order?</div><div>Or may be you suggest not to install(TARGET) for the concerned target and write install(SCRIPT) replacement for those?<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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 <a href="https://fastlane.tools" target="_blank">Fastlane</a>, 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).</div></div><div><br></div>-- <br><div dir="ltr" class="m_5766365985255384731gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>New book released: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div>
</blockquote></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eric<br></div></div></div></div></div></div>