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

[Ziller Eike]

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

>> So that would always contain the Qt sources, documentation and examples too?
> 
> Yes, Kai wrote he sees no point to be able to not install docs & examples together with SDK as suggested in QTBUG-34870. So once Qt Creator isn’t there, bundled frameworks use @rpath, is there any point to have an installer that just copies files if Finder serves this purpose just fine?

Except for the open question of registering the stuff in Qt Creator, for the current opensource installers we probably wouldn’t need more than that.
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.
Another thing that I think we should actually do in an installer, even though we currently do not, is to do system checks and warn users if these are not fulfilled. 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).

>> I just want to mention here that there *is* the plan to get rid of the requirement to install Qt Creator from the installers.
>> There are several possible ways to solve that and I think the discussion of what is the preferred way to do it is not over yet, but I think there is overall consensus that it should be done.
> 
> Great to hear!

The currently discussed ideas here still involve the installer though.

> “double-click .qtsdk to register" only works if you have exactly one Qt Creator install on your machine. Of course there still would be “drag qtsdk thing into Qt Creator” etc, but I don’t really see the advantages.
> 
> Correct me if I am wrong but there’s single ~/.config/…/QtCreator file, so even we have several QtCreators all of them gonna see some SDK registered by the other.

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.

> Of course triggering registration and copy Qt5.x.y-spec.qtsdk with Qt Creator requires Qt Creator to be there. It may be explicitly written on .dmg background image. We can even put link to Qt Creator download too for convenience. I have ready bash scripts that do all the layout and dmg build.
> 
> Still Qt5.x.y-spec.qtsdk would be just a normal folder containing whole SDK for given target. So you can always drag & copy it anywhere you want and use it from command line if you don’t like Qt Creator.
> 
> What’s more since dmg is mounted RO HFS filesystem, so you can even try the toolchain without copying it anywhere, which isn’t possible right now.

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.

>> I’d guess that the more common case would be that people double-click Qt Creator without double-clicking the .qtsdk (which they have no idea what it’s supposed to be).
> 
> If Qt Creator is installed you will not see .qtsdk extension and instead of folder icon you will see some custom icon that will intuitively make you click on it.
> 
> If it is not installed it will look as regular folder and Finder will let you step into it when you double click it.
> 
> This is how it works for many other apps and it works well.
> 
>> I’m convinced that the AppStore is the only reason why Xcode is having “everything in the bundle” nowadays. Not because it would make sense usability-wise.
> 
> Aside „everything is in the bundle” and simple install & updates, it is also easier to manage multiple SDK or Xcode Betas, being just separate .app, you drag around trash or overwrite. It is far more simple that previous .pkg based installer that requires launching command line uninstall-devtools to get rid of stuff.

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.

> Also now switching between command line toolchain versions is as simple as selecting it from combo in Xcode Prefs or launching some fancy extra manager apps, but there is also xcode-select.

That is independent from where the SDKs are installed.

>> I don’t think the normal user of Xcode cares if the SDK was installed within the Xcode.app or not. It’s not that Xcode didn’t come as a installer for years, and it’s not that installers are completely alien on OS X.
> 
> I don’t claim that installers are alien, but just custom installers. Also .pkgs serve special purpose, they modify your system, i.e. installing drivers, quick time components, etc. etc.
> Also before Xcode 4, Interface Builder and many other tools were separate from Xcode itself.
> 
>> The “Install Command Line Tools” thing in Xcode is one of the things that are really *bad* usability-wise now. Apple doesn’t care, because for Apple this is the “if you are not using Xcode we don’t care much” path, but I don’t think we want to follow that.
> 
> In fact in 10.9 there’s no more Install Command Line Tools, since there’re shims that pick up installed Xcode toolchain, or when there’s none pops a dialog to install one. Again it is just convenience, not necessity.

That still needs system wide installed tools for that though. So is that what is done at first Xcode startup, where it “installs required components” or something like that? (into locations needing elevated privileges btw) And actually I find that even more confusing now.
Anyhow, developer.apple.com/downloads still has “Command Line Tools (OS X Mavericks) for Xcode”.

> It provides UNIX compatible command line toolchain that works, compiles X11, autotools, OpenGL/GLUT stuff just fine.
> 
> That’s why a having QtCreator Install Command Line tools would be similar, it would just make something that you may do manually anyway. Many other apps such as TextMate, Keleidoscope do that, and users like it.

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

>> I’m actually glad that we got rid of system wide installs (that we did for Qt4), so I don’t think system wide installs would be a good direction to go. It’s also not very common to do that on OS X.
> 
> Well, I do agree that forcing system-wide install may be a bad idea and I am against to mess around with /Library, which needs elevated privileges.
> 
> That’s why Qt5.x.y-spec.qtsdk should be just a folder, and all registering and auto-copying stuff should be convenience not necessity. You can always put Qt5.x.y-spec.qtsdk/bin in your PATH, symlink to /usr/local/bin or do whatever you want, and copying stuff into Qt Creator.app/Contents/SDKs would be just another convenience not necessity to let user remove SDK directly from Qt Creator or remove everything putting Qt Creator into trash.
> 
>> That would be highly unintuitive (after all it is supposed to be *installed*), and counter productive to the “I don’t want Qt Creator” case (you can’t “install the tools” and trash Qt Creator). Again, Apple doesn’t care with Xcode, I think we should.
>> I can’t follow that calculation.
> 
> If I read it correct, it was about creating and maintaining SDK install packages per platform. What I am saying it would be less burden because instead building+packaging_installer+packaging_dmg it would be replaced with building+packaging_dmg.
> 
>> We’d still need the online installer functionality *somewhere*.
> 
> That’s why I think Qt Creator is best place for that. If someone want to use command line, it won’t use anyway some extra GUI manager. More apps, more clutter.
> 
> I opt for really simple solution that leads you do .dmg for given platform, as simple as a lists with Download button that opens a URL to .dmg. I don’t think we even need to use any Qt installer functionality, unless it has some download dmg, mount and copy functionality out of the box.

You (or at least I) want notification of updates, versioning of components, dependencies between components (if you look a bit further than the pure “we have a bunch of independent sdk folders”) etc etc.
So effectively the same functionality of the “external” online installer. But even if the “installer” in qt creator would “just” show a list of components and download some extractable package, it would be additional functionality implemented in Qt Creator that already is implemented in the installer. And we also already set up the infrastructure for online installers/updates for the installer framework up for the other platforms.

> But I really think packaging stuff twice, 1st time into dmg, 2nd time into installer.dat is bad idea.

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.

>> I’m all for self-contained, relocatable Qt (@rpath, plugins in bundles, etc), and afair the corresponding Qt Project maintainers too. It’s a bit independent from the question of how to distribute Qt packages for developers though.
> 
> Great. If you need any support, testing anything let me know.

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

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.


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