Mac/Cocoa binary package available for testing

I discovered the Cocoa support wasn't built in after hours of frustration over the weekend trying to port my Qt app to OS X. Thanks for not mentioning it until now!

Why not have two binaries, one 64-bit and one 32, or one PPC and one Intel?

Rik: What do you mean? The Qt API is the same in both packages. (and on all platforms.)

Matthew: I think 64-bit cocoa / 32-bit carbon is a good option. PPC / Intel is not so good, the major point of universal binaries is that you shouldn't have to worry about the CPU type :)

The first option would leave out the ones who want to test Qt/cocoa but can only run 32-bit apps though. This can happen if they have an app that is not 64-bit clean yet, or if they are using one of the first generation intel systems from Apple which were 32-bit only.

I want 32-bit cocoa. So it's either going to be 64-bit cocoa PPC + Intel /32-bit carbon PPC + Intel, or … just separate Cocoa vs Carbon downloads. I'd go with the latter. Provide Cocoa by default, and provide Carbon as an optional download. Let people use the technology that will continue to exist in the future by default.

P.S.: why not use http://mollom.com to prevent spam in your comments? There's a WordPress plugin available: http://wordpress.org/extend...

I don't think you guys necessarily made a mistake with 4.5 because the new Cocoa code requires 10.5 which is the latest version of OS X. I tend to compile Qt from source but I still use Carbon because a number of our users are running older machines with 10.4. So from my perspective the right split might be ppc/32 + intel/64. The only gain for ppc/64 would be G5's, which shouldn't get the speedup you should get with intel/64. The only gain those G5's will get is being able to address huge amounts of memory, and if you're doing that (or rather demand that) then you can't even run on a 32 bit system so you're probably best off compiling Qt yourself with just 64bit support.

When deploying the Qt app, one could use lipo (see: http://developer.apple.com/... ) to strip out single architectures of the release/deployment Qt libs. And the 500MB debug libs will fill only the developers hard disk. So, shipping the full monster should not be too bad, what do you think? :)

Since the Cocoa binaries are not part of the official release, is it stable enough for production use? I thought the 4.5 release included reliable Cocoa-64 support.

I just want to second what Alessandro said. We already go to the trouble of striping out the PPC parts of the Qt 4.5.0 carbon libs when we build our app since we've decided to only ship for Intel. Striping out 64-bit Intel as well would be pretty simple. Also the size of the debug libs is almost irrelevant to us since we never ship those. So my vote is 4-way universal all the way! :)

@Sean M: I'm curious why you chose to strip out PPC. Since most apps based on Qt4 are built from the ground up, there is no reason to chose Intel only to make a port from Windows/Linux any easier. Perhaps I'm just being defensive, since I'm writing this on the G5 I use to develop software myself. :-)

Thanks for the feedback! We're debating the binary package issue here at the Qt Software office as well, hopefully the right solution will find us before the 4.5.1 release. What seems certain is that it will be a pure Cocoa package, and that it won't be the default package (that's to late for 4.5 anyway).

morningstar: The "unsupported" part refers to the binary package only, since it didn't go through the standard release process. If you build Qt/Cocoa from source then that is fully supported.

I think that shipping quad-fat or tri-fat binaries so that people don't have to worry about their chip type amounts to treating customers like idiots and wasting their disk space and network bandwidth (and electricity with it) at the same time. Binary sizes are getting ridiculous - the developer tools package I downloaded last night (XCode 2.5 as I have Tiger) was nearly a gigabyte; the Qt SDK download for the Mac is nearly half that. This is not necessary for developers, because they should be expected to know what chip type they have anyway. There's a case for it with library-only downloads for end-users, though.

We should get away from fat binaries, in my opinion; it was a good transitional option, but four-architecture binaries are too much.

Glad to hear out-of-the-box 64-bit support is coming. I can't care less about what API it's coded to. As long as it work and that's why I want to try Qt in the 1st place: free from the tyranny of the OS vendors. :)

Now speaking of as long as it works. I read it in Qt doc somewhere that there are still a few features missing from Cocoa implimentation, like drag-n-drop. Are those fixed?

If I had to make the call I wouldn't even bother shipping universal binaries for developer packages. Let the developer get the stuff he needs, and when the developer wants to DEPLOY he can build his own UB libraries. I think it would be more useful to have prebuilt redist packages in release mode -- PPC32 Carbon, PPC64 Cocoa, and Intel -- that end users can install or that application distributors can bundle.

Seriously, in my opinion one of the biggest problems Qt has today with cross-platform deployment is that there ISN'T a standardized end-user redistributable, leading to DLL hell on Windows and who knows what's going to happen on Mac. (I don't know and I USE Mac!) It's absurd to ask an end-user to install the developer package because those come with the huge debug symbols, header files, sources, and build tools that just clutter up the system.

Having centralized, standardized redistributables for Windows and Mac means that there's a well-known interface that application developers should target for maximum compatibility.

@Adam Higerd

That is the best suggestion I have ever read on these blogs. I think it only pertains to Mac and Windows (Qt is already omnipresent in Linux), but can't think of a single reason why this wouldn't be a major priority for Qt software.

@Will Stokes: We strip out PPC because the powers-that-be decided we're not going to support PPC in this version of our product. And since the product in question depends on deliverables from other divisions of our company the decision whether to support a given architecture effects quite a lot of code, some of which needs to be highly optimized (eg: SSE, Altivec, etc) to produce acceptable performance.

@Adam Higerd: On Mac we solve the re-distributable problem by placing the Qt frameworks (just the release builds, of course) in .app/Contents/Frameworks. This allows us to avoid a DLL-hell type situation and makes the fact we use Qt completely transparent to the end user. Also, I'm guessing you don't use Qt on Mac (at least the commercial edition) because they currently distribute the debug builds separately from the release builds. So while they may be quite large, they are also entirely optional.

In general, the position I'm advocating is for them (the Trolls, or are they Noks now?) to maintain the status quo. Distributing a set of 4-way binaries for Cocoa seems to me to be the natural extension of what they do now, which is distribute 2-way binaries for Carbon (which as we all know is the best you can hope for in Carbon).

From my point of view, PPC is the past, and I have decided not to support it in my application anymore, and it's fine with my market. I guess sometime in the future, Nokia will also think PPC is dead. But at least for the time being, don't make the PPC support mandatory.
For testing, first thing I would like to see is Cocoa 32, to see if that makes any difference (speed, reliability) with Cocoa 64.

The semi-official view from us trolls is that the mac binaries exist primarily as convenience for developers who want to skip the compile step. This means we want to have as broad coverage as possible for the packages. If it's possible to develop Qt applications without knowing what CPU type you are using, then I consider my job well done :)

For deployment I would go for the private frameworks approach, and then do a custom build with the options I need. With 4.5 we've even made it easy with the macdeployqt utility. (located in QTDIR/bin in the 4.5.0 source package; it missed the binary package due to a packaging fumble. 4.5.1 will have it.)

There's a new Qt/Mac documentation page up at http://doc.trolltech.com/4.... which might also be of interest.

I'm well aware how to use private frameworks. Like I said, I use Mac, and I've deployed Qt-based software before. It's absurd that I have to add a huge set of frameworks to each and every app bundle I ship, especially if it's a piece of software that has multiple executables (and the one I'm working on has three!). This gets even more absurd when you want to include QtWebKit in your application, since QtWebKit is ENORMOUS.

Should Nokia succeed at getting Qt "Everywhere," this problem is only going to magnify in scope as more and more apps with Qt dependencies become popular.

@Adam

I can appreciate your frustration, you don't want to have a copy of Qt in your bundles, but it's very hard to have a canonical version of Qt for the Mac as everyone has different wants and needs. We've had to close the doors on some configurations with Cocoa (no static for instance), but there still are many, many ways to slice and dice Qt. This is further complicated by the fact that you can really only have on "shared version" at any one time. In other words, if you install the frameworks into /Library/Frameworks they will work for you, but if someone installs their own version with their own fixes, you app might be in trouble. We could maybe pursue getting Qt included by Apple, but it would be very likely that it wouldn't see an update until the next 10.x OS update.

If you want the convenience of a drag-and-drop install from a disk image, the private frameworks is probably your only bet. If you want to share between apps, you can use an Installer package and install your frameworks in a special place. Though you have to make sure each of your installer packages has Qt.

There's no good answer for the moment, maybe in the future, but not for the moment. On the plus side, Macs normally have a lot of disk space :-/

Adam - this is what Library/Application Support is for. We put our copy of Qt in a subfolder of that, and share it amongst our various apps.

I don't know if it actually works but I read it that OS X Frameworks have version capability in it:
http://developer.apple.com/...

Maybe that will help avoiding the possible DLL hell?

@Trenton: I see where you're coming from, but it's not a problem on Linux -- people share Qt apps across distros all the time, even Qt Creator has binaries that'll work with any sane build of Qt on a standard Linux system. If it works there, why can't it work on Mac? Mac is a very homogeneous operating system -- there's very little variation from system to system when it comes to the installed set of libraries. That's one of the big reasons to USE a Mac -- every Mac can be expected to have a consistent base, no worries about drivers or libraries or system configuration.

In other words, your argument is self-defeating. If Nokia were to make an "official" Qt/Mac end-user redistributable, it would simply join the Mac ecosystem in the same way: Everyone who needs Qt has a compatible version of Qt. No one should ever have to worry about whether this Mac's Qt has this feature or that Mac's Qt doesn't have that feature as long as the version number on the library is at least some required threshold. Mac isn't the "hacker's playground" that Linux is -- your typical Mac end-user (and even your typical Mac developer!) isn't going to be running customized libraries. No one would have to install "their own version" if there's an official standard that apps are expected to conform to. And if some developer's application needs a customized build of Qt, they can still include their modified versions in the app bundle just like they already do.

@Paul: Good to know; I'll research this further.

@Trenton: Upon further thought, I guess what I'm trying to say is that Mac users DON'T have different "wants and needs" like Linux users do.

This does leave open the question: What configuration SHOULD the canonical package have?

@Adam: Users, yes. Developers, no. At least from as many support issues/requests for hotfix patches that I have seen in the past. If everyone would agree to use the binary package, that'd be great, but it's not likely. The configuration for canonical is even more up in the air as we are in a transitionary period from Carbon to Cocoa, PPC to Intel, and 32-bit to 64-bit. It's impossible to find a one-size-fits-all package right now. I expect in a couple of years, it will be easy: x86_64 Cocoa. Until we've reached that point though, we are going to have to these growing pains. I hope we get there some day, I really do.

@stephenju: We already put version information in our frameworks, but the separate versions is targeted at major version upgrades (i.e., storing Qt 4 and Qt 5 in the same framework). When we get to that point (which will hopefully be a long time), we will certainly see about doing something like that.

On the topic of size, I'm curious what some of you might think about using frameworks versus static linking. With Cocoa static linking it out, but since I still use Carbon (so I can support 10.4) I'm still statically linking. Why? My impression is that the linker is smart enough to cull symbols (aka qt functionality) that I don't actually use. This should result in a smaller binary and thus smaller disk image for my users to download. I suspect there is a pitfall with doing this: unlike on Windows where my NSIS installer copies over various Qt dll's, on the Mac when you launch my app you have to load the entire thing, aka all the statically linked in Qt code. Thus if I used frameworks these would be loaded on demand. E.g., QtWebKit would not be loaded at all, or only after a major delay, in most cases. Are my suspicions correct? If so I suppose in the long term it would make sense to transition to shared libs (frameworks).

@Trenton: My entire discussion was about users, not developers. Developers should be in a position where they know what they need, and they're probably wise enough to know which of the various packages to download, or they can build their own if the default distribution doesn't suit their needs. I'm not worried about the developers. :P

@Will The only real benefit for static linking on the Mac is saving disk space and maybe some hassle in distributing which we've taken care of with the macdeployqt tool. If you use dead code stripping and know exactly what plugins to use, you will beat out using private frameworks with space on disk. However, performance- and memory usage-wise, there should be no real difference. There are other benefits to using private frameworks, such as component upgrading, adding further functionality with plugins, etc.

Be careful with dead code stripping though, I've seen it strip too much and the only real way of solving it is to simply not use. In other words, test it out before you ship.

@Adam: OK, I see. I just hope that most users never even have to worry about if their program uses Qt. It should just work. :-D

@Adam: adding my two cents here.

1) I think what we need is official Qt binary releases for all platforms (either we do it, or together with the platform distributors themselves)

2) and, a cross-platform tool that packages your Qt app into a nice bundle/installer/whatever.

Easier said than done ;D