[Development] Co-installation & executable naming rules

[Thiago Macieira]

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.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120921/ae0e6b90/attachment.sig>