[Development] Why custom installer on Mac, why not using @rpath?

[Ziller Eike]

On 18.06.2013, at 12:44, Adam Strzelecki <ono at java.pl> wrote:

> Probably I am duplicating discussion at: https://bugreports.qt-project.org/browse/QTBUG-31814 but anyway it would be worth to let everyone know the insights made here.
> 
>> Because we are using the same installer framework for all platforms. Which has the advantage of a) less reproduced work for packaging, b) the ability to at some point provide online updates, c) probably more
> 
> Yes, that fair point. Still once we don't need any patching (see below) I don't see the point of having installer app at all, if we have Qt5.1.sdk folder in the dmg that can by dragged anywhere by the developer, this makes the maintenance even easier :>

Since Qt is huge I would claim that many people would prefer to have a component selection where they can choose what parts they'd like to omit. Sources or no sources, extra tools or not, which Qt versions for which target platforms they actually want etc. We are also working on getting online installers again, where only the parts that you selected are actually downloaded.
Also the installer automatically registers all installed Qt versions with the necessary tool chains (think e.g. SDK/compiler settings for mobile platforms) in the installed Qt Creator.
And I'm most certainly still missing some things why it is preferable for Qt packages to have a real installer already now or in the future, instead of just a disk image with the contents.

>> /Developer does no longer exists since some Xcode versions, so there is no standard install location for "development tools" anymore.
> 
> I agree. Apple dropped /Developer because Xcode.app is now self contained app, which resolved long-standing problem with uninstallation and managing multiple Xcode version, now you just drag Xcode.app to trash.

And even though Xcode itself is now "just" an application, itself acts as an installer for additional components, like SDKs and documentation packages.
The Qt installer doesn't install anything outside the installation directory, which you can also just remove to "uninstall", and installing into different directories will create independent installations that do not conflict.


That said, I'm not against improving the structure of Qt/Mac regarding e.g. rpath, plugins etc, but that discussion is independent (*) of the discussion of using an installer for Qt on Mac or not.

(*) in the sense of that even if there was no patching needed to make Qt work in principle without an installer, there are enough reasons to use an installer anyhow.

Br, Eike

>> I already talked to Morten about that a while ago, and there's probably nothing preventing us from switching to using @rpath, since Qt 5 no longer supports the older platforms that don't have it.
> 
> Great to hear that.
> 
>> The installer would still need to patch the installed Qt though, because qmake and QtCore have paths hardcoded / compiled into them (e.g. the paths returned from QLibraryInfo::location). That was only not necessary for the Qt4 installers because they were installed into a predefined location. You could *not* change the install path in the Qt4 installers.
> 
> Ad detailed at https://bugreports.qt-project.org/browse/QTBUG-31814#comment-206336 I don't see any reason that qmake and QtCore could not use paths relative to current executable rather than hardcoding absolute paths.
> 
> This together with @rpath will make both SDK and Qt apps work well regardless where user puts them or moves them afterwards and follow platform specific app directory layout.
> 
> Also this would resolve https://bugreports.qt-project.org/browse/QTBUG-29550
> 
> Cheers,
> -- 
> Adam

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