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

[Ziller Eike]

On Aug 13, 2014, at 11:07 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:

> On Tue, Aug 12, 2014 at 07:08:45PM -0400, Jake Petroules wrote:
>> On 2014-08-12, at 06:50 PM, Adam Strzelecki <ono at java.pl> wrote:
>>> I agree that such facility should be provided internally while
>>> implementing Phase II changes.
>>> 
>>>> (1) Add qmake options QMAKE_EMBEDDED_FRAMEWORKS,
>>>> QMAKE_EMBEDDED_LIBRARIES, QMAKE_EMBEDDED_PLUGINS, each taking a
>>>> list of absolute paths and/or objects; applies to any qmake bundle
>>>> target, app, framework, etc. Does nothing for non-bundle targets.
>>>> Does nothing outside of OS X and iOS.
>>> 
>>> Makes sense.
>>> 
> yes. except that i want these to be called QMAKE_BUNDLE_*.
> this is irrespective of x-platform use. i like the idea of calling the
> functionality "bundling".
> 
>>>> (1a) "objects" (don't know what this is called in qmake but INSTALLS works similarly) meaning:
>>>> 
>>>> weirdlib.src = /Library/Frameworks/WeirdLib.framework
>>>> weirdlib.dst = $$join($$QMAKE_EMBEDDED_FRAMEWORKS_LOCATION, SubFolderForSomeReason)
>>>> weirdlib.headers = true
>>>> weirdlib.variants = debug release
>>>> QMAKE_EMBEDDED_FRAMEWORKS += weirdlib /Library/Frameworks/Sparkle.framework
>>> 
>>> Thumbs up. Good idea.
>>> 
> i'm not so sure about the details.
> the thing is that the .dst specification is way too "precise", thus
> making x-platform use impossible. even the existing QMAKE_BUNDLE_FILES
> isn't that precise (which enables supporting ios and osx bundles without
> changes to the project ... provided somebody bothers to polish up the
> qmake changes that are supposed to make this actually work).
> 
>>>> (4) User's OWN responsibility (NOT qmake's) to set QMAKE_RPATHDIR
>>>> for their application/library/framework to whatever they like -
>>>> @executable_path/../Frameworks, $$[QT_INSTALL_LIBS],
>>>> /Library/Application Support/FooBar/Frameworks, etc.
>>> 
>>> I disagree here. This should work out of the box for any simple or
>>> existing Qt app, regardless what Qt modules it uses. Requiring
>>> changes to existing projects is bad idea.
>> 
>> I disagree that it's a bad idea, but putting on my qbs hat for a
>> moment and thinking about Export { } I'm willing to concede here.
>> 
> i don't understand what this has to do with qbs Export {}.
> 
>>>> (1) NO changes are made to USER targets by qmake, ever. That means
>>>> qmake MUST NOT set any rpaths in user targets unless EXPLICITLY
>>>> given by the user with QMAKE_RPATHDIR (currently you are doing this
>>>> but only as a transitionary measure and it will be removed once
>>>> support for copying frameworks is added).
>>> 
>>> Correct me if I am wrong, but changes are needed to all existing
>>> projects or/and user environment (DYLD_...), otherwise their freshly
>>> built app won't start and we get plenty of post "why may app no
>>> longer starts with new Qt release".
>> 
>> Use the QT qmake variable to determine what frameworks to copy by
>> default and you don't have this problem.
>> 
> i'm kind of losing at least one of you guys here.
> it's beyond obvious that existing projects *will* need at least one
> modification: CONFIG += bundle_qt (and possibly additional
> QMAKE_BUNDLE_* for non-qt dependencies). there is no way i'd allow
> a major behavior change like making this the default.
> and when these options are enabled, it seems pretty much a no-brainer


> that qmake would also automatically add the right rpaths to make these
> bundled dependencies actually useful. why would you ever *not* do that?

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.

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