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

[Ziller Eike]

On Nov 28, 2013, at 12:53 PM, Adam Strzelecki <ono at java.pl> wrote:

>> 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.

I don’t know how what you say relates to what I said above.

>> 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.

It was an example. We’ll always have issues that would be good to warn about (e.g. outdated Xcode, which we don’t really support,…)

> 
>> 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

Also in your case (3) some (administrator) user needs to put/install the SDKs inside Qt Creator. Actually I don’t think 2&3 are different at all. Why should we do different things in these cases? It just creates inconsistencies, and makes it harder to test.

>> 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?

I don’t see principle problems with that, but that’s more a question/request to the installer framework guys. I don’t quite see the problem with requiring that people who just want the relocatable Qt binary archive download exactly that to begin with. We already provide that for the Qt Creator standalone version for all installers (since Qt Creator is relocatable): http://download.qt-project.org/snapshots/qtcreator/master/latest/installer_source/

>> 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.

I could imagine that it’s useful e.g. if you do automated generation of build vms (I think installers support silent/headless install), and also Xcode *is* overhead for e.g. pure build slaves.

>> 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.

You cut something off here. I meant for e.g. TextMate, most people care about the app, not the command line tools. I claim that’s different with Qt and Qt Creator.

>> (…) 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.

See below :)

> 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.

MaintenanceTool is basically a copy of the installer without the data.
Reg. command line interface you can have a look at
./MaintenanceTool.app/Contents/MacOS/MaintenanceTool —help

e.g. 
--checkupdates                                       Check for updates and return an XML file of the available updates

which we use for the “online update checker” plugin in Qt Creator (which still has to be reactivated for upcoming online installers).

And the use case of not wanting Qt Creator was the starting point of this whole discussion, where I already said that it is a use case that we *do* want to support.

>> 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.

We can provide uncompressed dmg images instead, if that is your concern ;)
The dmg is really just used as a simple container here, since on Mac it’s not all bundled within a single binary as on the other platforms.

>> 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 ;)

It’s not that we ask “why change”, it is pretty clear that we should get rid of that legacy of supporting pre-10.5 or something like that.

>> 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.

./configure  -bindir <dir> -headerdir <dir> -libdir <dir> -plugindir <dir> ……
But I agree that hardcoded absolute paths in the qtcore lib are ugly, and that in the “default” case it could probably use paths relative to the qtcore library. (Deployment into applications could still override that behavior with qt.conf like it is done now.)

Anyhow. We agree that making Qt “relocatable” at least on Mac would be desirable. It seems that we do not agree that it would be desirable to get rid of installers on Mac. Since the latter is basically dependent on the former, I suppose we can just postpone any discussion and actions regarding installers until Qt *is* actually relocatable.

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B