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

[Oswald Buddenhagen]

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?