Comments inline. On Oct 17, 2012, at 12:19 PM, Daniel Price wrote:
> The idea behind frameworks on OSX is that you bundle the library, it's > headers and any associated resources (images, nibs etc) into one unit that > the Finder sees as a single file. > > That's all very well for the rare occasion in which a Cocoa application needs > to include some other framework (like Sparkle) or for system-wide frameworks > but for Qt app it has the following consequences: Not sure I would agree with "rare" but I'll move on. > > 1) Because Qt has to be deployed with the .app, you have include the > Frameworks which also includes every single .h file, bloating the size of the > .app. Even a trivial app must include QtGui which is *huge*. A simple install rule will strip out the headers so they are not included in your app bundle. > > 2) Because the install_names of the .dylibs deep inside the bundle are > typically wrong, they have to be changed so that the application binary can > find them. The binary's install_name table also has to be updated. So you > have to pass long file paths to the install name tool > (@rpath/Frameworks/QtGui.Framework/versions/A/blahblah), either manually or > via a script. And each .dylib file needs to have its dependencies updated > too. Very error prione. Anyone who has ever deployed a QWebKit app on OSX can > attest to this. Write a script because if you are serious about development (not just doing some one-off app) you are going to be doing this over and over again. Write a script, get it correct then you do not have to worry about these "deployment" issues any more. > > 3) It's pointless. The Qt libraries include all their images etc in binary > form so there's nothing else in the bundle, beside the headers, which you > don't need. The only exception is the qt_menu.nib which you need to deploy > manually. Also, because you can't really 'share' the deployed frameworks > among multiple Qt applications, the memory benefits of Frameworks is negated. > And because you only ship one version of Qt, the version management of > Frameworks is negated too. Incorrect. You actually CAN share the frameworks between Qt apps. I do it with the project I work on. I have three Apps all of which share the same set of Qt Frameworks. Again, some scripting will solve this issue for you. > > Finally, the mac_deploy_qt tool should be avoided. It deploys everything, > including all plugins, regardless of if you use them or not, bloating your > application size. It's also proven to be pretty buggy in the past. <plug> I use CMake and its "BundleUtilities" function to do all of these deployment tasks and it works 100% of the time</plug> > > If you've put the effort into porting you app to OSX, do it properly. Build > Qt without frameworks, deploy the .dylibs to your bundle and use a post-build > script to set the install names. There's a tool called mac dylib bundler > which can do much of this work for you > (http://macdylibbundler.sourceforge.net/). See my comment from above. If you use CMake you can write (or copy) the proper CMake code to do all of this for you. Just my 2 cents. > > > -----Original Message----- > From: interest-bounces+daniel.price=fxhome....@qt-project.org > [mailto:interest-bounces+daniel.price=fxhome....@qt-project.org] On Behalf Of > Andrea Franceschini > Sent: 17 October 2012 16:17 > Cc: interest@qt-project.org > Subject: Re: [Interest] Is Qt Library for OS X frameworks only? > > 2012/10/17 Daniel Price <daniel.pr...@fxhome.com>: > >> I always build Qt on the Mac without frameworks. I have no idea why >> Qt/mac defaults to using fraweworks as they add no value (with one >> exception - the dummy menu nib) and just make deployment 1000x harder. > > I may very well be wrong on this but I thought frameworks get included in the > app bundle, hence making deployment way easier (but obviously heavier as it's > almost like statically linking libs inside the executable). I find the shared > libs deploy-once-run-everything better from an engineering point of view, but > I recognise Apple's bundles and frameworks have some good points (like > avoiding littering the filesystem with exotic libs that are only used by one > application). > > -- > Andrea Franceschini > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > This email is confidential. It may also be privileged or otherwise protected > by work product immunity or other legal rules. Errors and Omissions Excluded. > If you are not the intended recipient please notify the sender. Please delete > the message from all places in your computer where it is stored. You should > not copy the email or use it for any purpose or disclose its contents to any > other person. To do so may be unlawful. Email is an informal means of > communicating and may be subject to data corruption accidentally or > deliberately. For this reason it is inappropriate to rely on advice contained > in an email without obtaining written confirmation of it first. > > FXhome Limited is a limited company registered in England and Wales. > Registered number: 04172812. Registered office: Suite 4 St Giles House, 27 St > Giles Street, Norwich, Norfolk, NR2 1JN, U.K. > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
