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

[Adam Strzelecki]

Oswald Buddenhagen wrote:

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

Yup, that sounds better. So they will be:

	QMAKE_BUNDLE_LIBRARIES
	QMAKE_BUNDLE_PLUGINS

	QMAKE_BUNDLED_LIBRARIES_DIR
	QMAKE_BUNDLED_PLUGINS_DIR

Example:
	mac {
		weirdlib.src = /Library/Frameworks/WeirdLib.framework
		weirdlib.dst = $$join($$QMAKE_BUNDLED_LIBRARIES_DIR, SubFolderForSomeReason)
		weirdlib.headers = true
		weirdlib.variants = debug release
		QMAKE_BUNDLE_LIBRARIES *= \
			weird lib \
			/Library/Frameworks/Sparkle.framework \
			/usr/local/lib/liblua.dylib
	} else {
		weirdlib.src = /usr/local/weirdlib.so
		weirdlib.variants = debug release
		QMAKE_BUNDLE_LIBRARIES *= \
			weirdlib \
			/usr/local/lib/liblua.dylib
	}

@Jake: I don't think we need separate vars for frameworks and plain libraries. If their need slight different handling, we can figure out that checking extension.

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

If we drop OS X specific naming, then I don't see what isn't x-platform. Maybe weirdlib.headers is kind of OS X specific, but otherwise. Of course is someone needs to bundle some specific libraries, probably it needs platform dependent conditionals, because source location will be likely different.

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

From my perspective CONFIG += bundle_qt was more about doing bundling on build. But when this is left out, doing bundling on "make bundle" which will be equivalent of "macdeployqt".

> there is no way i'd allow
> a major behavior change like making this the default.

Completely makes sense to me. But if I understand correctly, you mean existing projects may expect macdeployqt? Or I am missing something else.

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

Yes, I believe we all agree on that now.

--Adam