[Development] Co-installation & executable naming rules

Mon Sep 24 09:19:30 CEST 2012

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

> On sexta-feira, 21 de setembro de 2012 16.47.11, Thiago Macieira wrote:
>> Include the major version number (5) in all library base names, like on 
>> Windows, on all platforms. On Windows we already have QtCore5.dll and 
>> QtV85.dll, so I recommend having libQtCore5.so.5. For Mac, I'm not sure of
>> the  naming scheme, but the recommendation applies.

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

Br, Eike

>> This recommendation also applies to the static library archives 
>> (libQtCore5.a), qmake library files (libQtCore5.prl), libtool archives 
>> (libQtCore5.la) and pkgconfig files (QtCore5.pc). CMake files already have
>> the  version number. but in a different place (Qt5Core).
>> 
>> I recommend harmonising the cmake names, either by changing them to QtCore5
>> or  by changing the library naming to match the cmake files (libQt5Core.so,
>> Qt5Core.pc, etc). Or one of the other alternatives at the bottom of this
>> email.
>> 
>> PS: this recommendation does not apply to executables. See follow-up email.
> 
> For executables, the situation is similar. The difference is that executables 
> have three categories, not just two:
> 
> 1) executables that are user applications
> 2) executables used for development; subdivides into:
> a) executables run by the user
> b) executables run only by the buildsystem
> 3) executables run by libraries
> 
> Fortunately for us in Qt, we have none that fall into the third category at 
> this point. But the proposal contemplates them.
> 
> 1) Applications
> 
> Application executables are not versioned and they are installed in standard 
> locations, like /usr/bin. They have only a base name and that's all. An 
> upgrade must retain compatibility with previous versions, upgrade user 
> settings whenever possible, etc.
> 
> Good examples are: qtcreator, assistant, linguist, qmlviewer, qmlscene, 
> 	qmlplugindump, qmlprofiler, xmlpatterns, qdbus, qdbusviewer, qglinfo
> Questionable: qdoc (does it parse Qt4 docs? do we retain any compatibility?)
> 	designer (the .ui format hasn't changed, but can it still save qt3 .ui?)
> 
> 2.a) Development, run by the user
> 
> For anybody else, the first sub-category would be a user application. But we've 
> not been good at this, so I had to create this category to accommodate its 
> only member: qmake, though qdoc may join it.
> 
> Since they're run by the user, they must be installed in standard locations 
> (/usr/bin). But since they do not retain backwards compatibility, they must be 
> versioned.
> 
> => qmake must be renamed, either to qmake3 or to qmake5.
> 
> Depending on how we categorise them, these executables may be 2.a) or 2.b):
> 	designer, lconvert, lrelease, lupdate, moc, rcc, uic
> 
> If we determine that they are run by the user, we must rename them and add a 
> version number.
> 
> 2.b & 3) Support executables, not normally run by the user
> 
> Since they are not run by the user, those executables should not be in 
> /usr/bin. Instead, they should either be in /usr/libexec/<key> or in 
> /usr/lib/<key>
> 
> The <key> component depends on how shared these executables are. 
> 
> All the executables I listed for 2.a) could be 2.b), plus a few that are 
> definitely never run by users, like syncqt and mkv8snapshot. If we determine 
> that they are not run by the user, we should move them to a suitable location 
> and choose a "qt5" key.
> 
> Future, hypothetical executable needed at runtime, would be installed to the 
> same location if they are shared by different versions of Qt 5.
> 
> The exception would be an executable that is used by a library that has two 
> different binary versions. In that case, they must be in that directory above 
> *and* be versioned.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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