Quite possible I’m misunderstanding something, but…
As you said, I really don’t care much at this point about the RPATH.
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. 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. Most frameworks I’m familiar with have the install name set to @rpath/My.framwork/my. I use add_custom_command to correctly set it, but still seems like this is broken.
The library I’ve been testing is iperf, it is relatively straightforward, so it makes a good test case. I’ve added CMake and it is at https://github.com/palmerc/iperf.
> On 19 Mar 2018, at 12:54, Brad King <[hidden email]> wrote:
> On 03/12/2018 10:36 AM, Cameron Palmer wrote:
>> So after a bit of hacking it seems that Cmake should provide something like:
> For reference, this refers to a previous post:
> Bitcode and CMake
> https://cmake.org/pipermail/cmake/2018-March/067191.html >
> with the goal of using `-fembed-bitcode` while avoiding a warning:
> ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
>> Which would pass -fembed-bitcode to the compiler and linker and remove
>> the option in Darwin.cmake for -Wl,-headerpad_max_install_names in
> One may avoid the `-headerpad_max_install_names` option with this:
> https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html >
> There is no reason to build with any rpath set for the build tree
> when one cannot run the binaries on the macOS host anyway.
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".