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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development