Priority: P3: Somewhat important
Affects Version/s: 5.12.3
Fix Version/s: None
Component/s: Build tools: macdeployqt
Typically, install names for bundled libraries are specified in one of these ways:
- Path relative to executable (@executable_path, @loader_path).
- Path relative to LC_RPATH (@rpath).
It appears that @executable_path/@loader_path approach still has valid use cases (see https://codereview.qt-project.org/#/c/138349). However for common applications, @rpath is generally easier to read and less problematic.
The "macdeployqt" tool is capable of doing both (note bug
QTBUG-75762 though). It is unclear to me on what basis it decides whether to go with one or another. I suspect the "-no-rpath" option which can be passed to the "configure" script when building Qt from source.
All above lead me to a conclusion that user should be able to decide which install names strategy is best suitable for given project, regardless of Qt installation settings. Therefore, I suggest implementing one of following:
- Adding two CLI options to the "macdeployqt" tool: "-rpath" and "-no-rpath", which override default choice made by this tool.
- Adding one CLI option to the "macdeployqt" tool: "-no-rpath", which disables @rpath approach. That implies that @rpath approach is used by default, which is probably a breaking change. Note that maintainers of Homebrew Qt package seem to rely on current behaviour.
- Add some QMake variable which defines which approach is suitable for project.