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

[Ziller Eike]

On Aug 13, 2014, at 12:32 PM, Adam Strzelecki <ono at java.pl> wrote:

> 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.
> 

Discussed on IRC with Jake:
If QMAKE_EMBEDDED_FRAMEWORKS also worked for e.g. dylib targets, it would be possible to specify it also in the .pro files of bundled libraries and executables, and put the result into the main app bundle with smth like "weirdlib.dst = $$QTCREATOR_FRAMEWORK_PATH” (where QTCREATOR_FRAMEWORK_PATH is set in qtcreator.pri, which is already pulled in by all bundled libs, plugins and executables).
That way the plugins, libraries and other executables could specify the things necessary to bundle for them themselves.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B