[Development] Co-installation & executable naming rules

[Ziller Eike]

On 24 Sep 2012, at 09:49, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On segunda-feira, 24 de setembro de 2012 07.19.30, Ziller Eike wrote:
>> I don't think the recommendation applies to Mac.
>> 
>> Usually you won't have globally installed Qt. Most applications deploy their
>> used libraries within the application's app bundle (that's what we have
>> macdeployqt for). Even if someone installs Qt globally it will be as
>> frameworks, not dylibs, and frameworks already have a versioning scheme
>> that includes major versions as binary incompatible versions of frameworks,
>> and has all major versions in separate directories (within the framework
>> bundle).
>> http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPF
>> rameworks/Concepts/VersionInformation.html
>> 
>> The frameworks + libraries + tools used for development are not installed in
>> system directories (/usr/bin and so on), but separately.
>> 
>> E.g. Xcode installs the frameworks + libraries + tools for the different SDK
>> versions (e.g. Mac OS X 10.6 vs 107) in different prefixes (nowadays even
>> within the Xcode app bundle). The ones referring to the versions currently
>> installed on the system might just be symbolic links, but point is that
>> they are usually used from these special prefixes. Nowadays you even need
>> to explicitly install the compilers etc in /usr/bin if you really want them
>> there. For Qt this means it is perfectly fine to either only have "user"
>> installations of the development stuff (~/QtSDK/...), or to install to
>> different prefixes for different binary incompatible versions, like we had
>> in the old binary packages in /usr/local/Qt4/... /usr/local/Qt5/...
> 
> Hi Eike
> 
> Thank you for the explanation. Looks like Mac has solved the co-installation 
> problem differently.
> 
> Let me ask you a question, though: suppose someone installs Qt 5 globally as 
> frameworks (/System/Frameworks/QtCore.framework), then updates Qt 4.8. Which 
> is the default symlink target?

There is no "default symlink target".
For development, you wouldn't use the globally installed framework directly, but through the different prefixes, that way always specifying a specific version. The files in one or more prefixes might be symbolic links to actual system wide installations, or not. So, if you have a setup where the user can separately update the system wide framework it probably would be unwise to use symbolic links, and just have duplicate development versions instead.

Btw, usually Qt 5 and Qt 4 would co-exist in the same framwork, i.e.
/Frameworks/QtCore.framework/Versions/5/...
/Frameworks/QtCore.framework/Versions/4/...

> And how does one select, at compile time, whether to compile & link to Qt 4 or 
> to Qt 5?

Since the versions that you *develop* with are installed in different prefixes, you adapt your -I -F and -L parameters for the different include & link paths (e.g. qmake does that for you).

When compiling for different Mac OS SDKs you'd set a different sysroot.

-- 
Eike Ziller
Senior Software Engineer
 
Digia Germany GmbH
Rudower Chaussee 13, 12489 D-Berlin
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B,  
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Tel: +49 30 63 92 32 55
 
Digia Germany is a group company of Digia Plc,
Valimotie 21, FI-00380 Helsinki Finland
Visit us at: www.digia.com
------------------------------------------------------------------
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message.