[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Adam Strzelecki]

Ziller Eike wrote:

> Can we please already now turn a cross-platform hat on, and at least think about options that at least do not right away block using the same for non-OS X?

Sure, this is just a proposition, "bundle_qt" (proposed in latter posts) seems to match it better.

> I do not see any reason why one shouldn’t be able to turn on copying Qt libs next to the application binary on Windows even without any changes on how Qt is built there. And usage of $ORIGIN on Linux doesn’t sound like a too bad idea to me either. “bundle_frameworks” already disqualifies using the same config option on anything non-OS X. (Aside from that, what is with dylib builds of Qt?)

Sure I do agree, that it should work for Windows too. But Windows is out of my scope. Anyone eager to do similar changes for Windows?

> (a) e.g. the Qt Creator build creates the application, and a whole bunch of plugin dylibs with DESTDIR in the bundle. The rpaths should just be correct from the start, probably no problem there, but some libraries there add dependencies to the Qt libraries that are needed. The main application is pretty minimal. So, depending on dylib target sub-.pro files, the list of Qt libraries to bundle with the *application* needs to change.

If we put bundled Qt library as Makefile target dependency either of executable, plugin or whatever. Each of this targets will trigger copy of missing libraries.

> (b) e.g. we have quite a few tools shipped in the Qt Creator bundle, which are either used by Qt Creator internally (e.g. for iOS device detection, starting the simulator,...), or shipped for convenience (the qbs that Qt Creator is linked against, etc). We definitely do not want to have separate Qt frameworks for these, but want them to use the frameworks from the Qt Creator application. With macdeployqt we tell it about the additional executables, and macdeployqt takes care of bundling additional required Qt frameworks, and fixing install names/rpaths correspondingly. 

As long it is same framework then it has single Frameworks folder, therefore there will be no doubling.

--Adam