> 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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
