[Development] Qt SDK for Mac OS X (was: New Qt 5.2 snapshot build #172)

[Adam Strzelecki]

> There are other installers though, either from Digia, or other companies (enterprise Qt packages, SailfishOS SDK, …) which have other requirements. Meaning that we need to have some kind of Qt installers for Mac anyhow.

Agreed. If you have dedicated machine for dedicated tools that works both for software providers and end-users.

> E.g. I think you should not install the Qt5 packages on Mac OS X 10.6 with Xcode 3.x, since that Xcode version’s install_name tool can’t handle MachO headers of binaries created on 10.8 (where we build the Qt binaries).

install_name_tool step is not necessary.

> Using ~/.config for that only works for single user installs. Which is not great especially if you install Qt Creator into /Applications and copy the SDKs into it. Registering SDKs would need to be done in Qt Creator.app/Contents/Resources/QtProject/… to make it available to all users of the Qt Creator that the SDK was copied into.

Again we are speaking about 3 different scenarios:
(1) no Qt Creator - no need to register anything
(2) single user, has multiple Qt Creator, and/or wants SDK to be at some place she/he wants, then Qt Creator needs to be somehow informed where is it (double click to register)
(3) multi user workstation (i.e. computer room at university) - you put SDKs inside Qt Creator (Xcode way), we don’t need to explicitly tell Qt Creator about new SDK, because it can figure out that

> If the Qt is at some point truly relocatable, we can just provide the 7z (or in dmg, or whatever format) of the component that is packaged in the installer in addition, for people which just want to extract and use that from the command line without bothering about installers. That would be indeed be no additional effort then.

That would be nice compromise. Would it be possible to put regular directory instead of installer.dat (which you say is 7z archive) in Mac dmg? So once Qt SDK is relocatable I can just copy or run SDK myself, but installer can still be used by the others?

> It is easier for people who solely develop using Xcode.
> And the last part is because for whatever reason Apple never cared to add some sort of uninstall into installers.

For whatever reason Apple never made its installer to be able to uninstall stuff. Actually it does degraded, pkgutil no longer can remove installed files. That’s a pity indeed. Fortunately OSX still follows well-known directories schema and still you’ve boms listing what files and where were installed.

> Anyhow, developer.apple.com/downloads still has “Command Line Tools (OS X Mavericks) for Xcode”.

Yes I find it confusing too. I wish they stick with Xcode only.

> There the application itself (without any command line tools) is what 99% of the users care about.

That’s why fortunately this is just optional.

> (…) it would be additional functionality implemented in Qt Creator that already is implemented in the installer.

You mean Maintenance Tool? Installer is gone once I eject SDK dmg. I have no idea if it has some command line interface? Then so, then ok. It may be a use for these who don’t want Qt Creator, otherwise why not putting everything in one place? Actually turning Maintanance Tool into Qt Creator plugin.

> Not sure I understand what you mean here. installer.dat is just a 7z bundle of the content that is extracted. That’s not the point. The point is the functionality of the installer.

DMG is bzip compressed image containing 7zip archive.

> Well, since the current approach works as is, the focus is currently on fixing more pressing issues in Qt5.

This is understood. If something works fine why change, however following such criterion most of corporations should cease their existence nowadays ;)

> Btw, to make the development tools really relocatable (and not only the Qt libs for use by applications) something needs to be done with QLibraryInfo data as well. I’ve no idea if that’d require completely changing how that works, or if it would be sufficient to throw some qt.config files into the “sdk directory” somewhere.

That would be just awesome. I never actually understood why it isn’t just resolving paths relatively to the path of tool binary, AFAIK only some embedded Linux have no functionality determining path of an image, but I guess no one would run toolchain there.

Regards,
-- 
Adam