> Afaics the suggestion is to never have the absolute path to the Qt frameworks
> added to the rpath at all. Which would make the rpaths *only* be useful for
> the bundled dependencies. So, when not using the “bundle stuff” option, it
> would require setting either DYLD_.... in the run environment, or explicitly
> adding the absolute Qt path to your binaries’ rpath, to be able to run the
> result. I still do not see why the absolute path shouldn’t be added when
> _not_ bundling Qt though.
>From very beginning a was about to add absolute rpath to Qt libraries in built
>executable, with one exception - when bundling is done on build, then we can
>add relative path. I was not about to touch existing workflow. Now we call it
>"Phase I" and changes are ready.
If bundling is done as separate manually triggered step, we need to replace
absolute rpath to relative in the executables, also to not keep any leftovers.
>From very beginning the reason I started this discussion was to never touch Qt
>libraries binaries once they are built (as now its done on install and
>macdeployqt). That's it. All other workflow changes was somehow ideas of the
>others not mine. Yet because I was asked how do I see "Phase II" (aka workflow
>changes) I stated my opinion.
Since both of us don't like idea of using DYLD_ and tweaking Qt Creator for
that, absolute rpath is IMHO necessary. Therefore I may ask you for a favor to
look at following changes:
https://codereview.qt-project.org/#/c/92072/9//ALL,unified
Because I am constantly loosing Jake in this and frankly I am getting confused
what to do.
--Adam
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
