[icu] Add support for macos rpath prefix macro

[adam-bloom]

Describe the pull request

• What does your PR fix?
  This PR implements a temporary solution for https://unicode-org.atlassian.net/browse/ICU-21458. It alters the ID fields of the built dylibs to add support for the @rpath macro on macOS. The new code is commented that it should be removed and replaced with calls to new configure options, if ICU-21458 is resolved.

• Which triplets are supported/not supported? Have you updated the CI baseline?
  Only macOS is affected.

• Does your PR follow the maintainer guide?
  Yes

[adam-bloom]

The macOS end-to-end tests are failing due to:

Failed to take the filesystem lock on /Volumes/data/work/1/s/.vcpkg-root:
    Resource busy

I don't believe this has anything to do with the changes in this PR, since this PR does not touch core vcpkg itself. Any ideas?

[JackBoosY]

I'd like @strega-nil to review this PR also.

[strega-nil]

@adam-bloom This is unfortunately a change we cannot accept; changing the output depending on whether a tool is found is unacceptable for us. How common is install_name_tool? When does it exist on the system? We can discuss better solutions depending on that.

[adam-bloom]

@adam-bloom This is unfortunately a change we cannot accept; changing the output depending on whether a tool is found is unacceptable for us. How common is install_name_tool? When does it exist on the system? We can discuss better solutions depending on that.

install_name_tool is in /usr/bin on macOS, which is a part of the write restricted system partition. I don't have access to older macOS installations, so I'm not sure when it was first included. The man page has a date of 2009 there - so likely 10.6 was the first inclusion. Additionally, Apple Developer Tools is listed as a vcpkg requirement in the readme, and another copy of install_name_tool is included with Xcode command line tools: /Library/Developer/CommandLineTools/usr/bin/install_name_tool.

In other words, I think every macOS system running vcpkg should be compatible with this. If, however, someone attempted to build an osx triplet from another OS (I'm not sure if that would even work without the macOS SDK...), they might be missing this tool and the step would skip.

I'll note that I initially did not have the if present check, since I assumed all osx vcpkg triplet runs would be from macOS systems that have this tool. I added that at the request of @JackBoosY

[strega-nil]

I agree with using find_program, but it should be REQUIRED, given what you're saying :)

[adam-bloom]

Is there a use case for vcpkg where a osx triplet is built on a non-macOS system? Or is this definitely safe to mark as required?

[JackBoosY]

@strega-nil The judgment is if(VCPKG_TARGET_IS_OSX AND VCPKG_LIBRARY_LINKAGE STREQUAL "dynamic"), I think it's fine.
Do you have any other questions?

@adam-bloom Nope.

[strega-nil]

yeah, the issue I have is making it non-REQUIRED; since we'll always be building on macOS, we should REQUIRED the program.

[JackBoosY]

So I think it's good now.

[JackBoosY]

Already merged from master.