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

Adam Strzelecki ono at java.pl
Mon Aug 4 02:17:34 CEST 2014


> In Xcode 6, when you create a new framework target, the first application target in the project is automatically selected for "embed in bundle" which you'd have to EXPLICITLY change for it to NOT be copied. Xcode 6 simply adds new and convenient UI for a practice that's been standard for over a decade. So yes, it does copy frameworks BY DEFAULT.

OMG, we were talking about two different Xcode versions. I am talking about Xcode 5 that does behave like I described, you are talking about Xcode 6 that indeed defaults to @rpath like you have described. But Xcode 6 is not final release, it is beta, so this may stay or not.

It makes completely sense to bundle project libraries into project application bundles. Yet Qt isn't part of your project, it is an external dependency, your project does not build Qt, it just links to it.

Does Xcode 6 automatically bundle an external framework added as dependency to your project, NO it does not.

> There is a very simple solution to this problem. I and the majority of developers do this:
> QMAKE_EMBEDDED_FRAMEWORKS = QtCore QtGui QtWidgets

"would" is more adequate here because we are talking about some possible setting not existing one.

> I'm not running on an SSD and I have the slowest MacBook Pro imaginable (2008). I can assure you there is no performance degradation whatsoever when copying frameworks as part of the standard workflow. Also, like I said before... QMAKE_EMBEDDED_FRAMEWORKS. A CONFIG option is not necessary because if you don't want to copy things, simply don't set QMAKE_EMBEDDED_FRAMEWORKS, or set it for release configuration only.

Sorry it doesn't make sense to me. Why would you like to specify which frameworks are to be copied if this is figured out by macdeployqt today automatically. Why someone would like to copy just some of the frameworks not all used by the application.

Reasonable choice it just to bundle when building ("make") or manually ("make && make bundle").

> For other users' sake we DO want to make it default. The workflows you want are foreign to every Mac developer out there.

Because Xcode 6 which is beta (not stable, may change, etc. etc.) does bundle frameworks which are part of the project? Qt are not part of your project, these are external dependencies. Xcode 6 won't bundle them if you add them as dependencies.

> New in Xcode 6.

You should say that at the very beginning.

> I'm curious why you think this will have a noticeable impact on performance. It is an unnecessary over-complication that actually leads to more bugs. Because this suggestion is contrary to every standard of Mac development, I will not accept this as a valid argument until you can provide benchmarks proving that there is a significant performance degradation.

Minimal GUI app's Qt frameworks weight around 20MB in release and 40MB in debug versions. This may be not much, but considering the fact app itself may be just few hundred KB this makes a difference. It won't have noticeable impact, unless you are working on network drives or whatever like that.

Altogether we have just different opinions about single post-process step, but we both agree we need @rpath working, we agree that bundling should be mark of qmake. So I believe decision whether bundle by default or not should be taken by Qt project maintainers, that's it. But we should have both options supported.

If we had BTRFS with COW this would be obvious choice, but we don't.

Regards,
-- 
Adam




More information about the Development mailing list