On Thursday 07 August 2014 14:55:06 Adam Strzelecki wrote: > The changes for qtbase are there: > > https://codereview.qt-project.org/91669 > https://codereview.qt-project.org/91670 > https://codereview.qt-project.org/91671 > https://codereview.qt-project.org/91672 > https://codereview.qt-project.org/91673 > https://codereview.qt-project.org/91674 > https://codereview.qt-project.org/91675 > https://codereview.qt-project.org/91676 > > This makes Qt SDK build: > (1) completely relocatable once installed > (2) all tools and examples refer frameworks relatively > (3) there is no hardcoded SDK in any framework or tool (except qmake which > keep SDK prefix) > > Next steps: > (1) changes to macdeployqt (removing absolute rpath & rewrite) > (2) remove rewriting in installer-framework
Please don't remove the rewriting of qmake itself. > FYI since installer rewrites absolute paths in frameworks, and there a none > now this shouldn't have impact on Mac SDK installer itself. Nice work! How does a launched application find the Qt frameworks that were installed by the SDK? And how do those frameworks find the plugins? I mean, if I compile an application, the path to the frameworks is set with the -F switch, which qmake knows as it's hardcoded. But how does the dyld know the path when the application is launched? Doesn't DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH need to be set? Is the Creator modification one of those changes? Also, how does QtCore find the plugins on behalf of every library? For example, when QtGui requests the cocoa platform plugin, what is the search logic? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
