On 03/26/2018 04:24 AM, Cameron Palmer wrote: > However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't > change anything as far as I can tell. The target is still linked with > -headerpad_max_install_names and the linker still complains.
Oops, I mixed up functionality with other platforms. On platforms that do not have `-headerpad_max_install_names` we generate bogus rpath content in the build tree to pad out enough space to replace it in the installed binary in the install tree. That behavior is turned off by BUILD_WITH_INSTALL_RPATH. On Apple platforms with `-headerpad_max_install_names` the flag is simply hard-coded. CMake would indeed need a new abstraction for `-fembed-bitcode`. Also, CMP0068 means the BUILD_WITH_INSTALL_NAME_DIR should be used instead of BUILD_WITH_INSTALL_RPATH. > Also, looking at policy 68 and working with the INSTALL_NAME, which > is the one thing you do care about, you cannot set the directory to > @rpath which seems silly. Sure we can. CMP0068 is only about the names of the CMake properties that influence the behavior. The INSTALL_NAME_DIR property can be set to "@rpath". -Brad -- 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-developers