[Development] Co-installation & executable naming rules

[Simon Hausmann]

On Friday, September 21, 2012 05:24:16 PM Thiago Macieira 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.
> > 
> > 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:

We just had a discussion in the Oslo office about this. We suggest to basically 
follow your proposal, with an addon to hide some of the uglyness it brings 
along.

Let me try to summarize very shortly. The base proposal would be to include 
the major Qt version throughout the project:

    1) Prefix the libraries, i.e. libQt5Core, libQt5Gui, etc.
    2) Prefix the pkg-config files (Qt5Core.pc, etc.)
    3) Prefix the binaries (qt5designer, qt5moc, qt5make) (note that this is 
referring to the binaries, not the user visible names or bundle names)

This allows for co-installation on all platforms (even on ones where there 
exists no problem of co-installation :)


Now this has some ugly implications, everyone will have to change the way they 
develop with Qt 5. In this context we have another interesting artifact: 
People who have been developing Qt for a long time as part of company efforts 
such as Trolltech, Nokia or now Digia will know that by now pretty much every 
developer has their own set of shell scripts to deal with multiple 
simultaneously installed Qt versions. We've had a few attempts at 
consolidating these efforts, with varying success (devtools / qset). Now one 
thing we came up with in our local discussion here is that maybe it's time to 
bring this idea forward and use it to solve the "uglyness" of co-installation 
in production environments:

We could have a tool (let's call it just "qt") that makes choosing between 
different versions/installations of Qt easier. The tool should read and write 
the existing Qt Creator Qt version registry (so that everything is always in 
sync). It could allow for forwarding calls to executables (qt --4 qmake -> 
call qt4's qmake; qt --6 qmake -> call qt6's qmake, same for moc, uic, 
designer, etc.).

It could also be a tool that's aware of defaults, so that just calling "qt 
qmake" would call qmake from the currently selected Qt version. It could also 
support changing your environment (if its front-end was a batch file and shell 
script), so that you could write "qt --set 5" and further invocations of "qt 
qmake" in the same shell/environment would automatically pick qt5's qmake.

If the tool used Qt Creator's registry of Qt versions, then it would also be 
suitable for Qt developers who may have different versions of the same major 
version installed on the same computer and want to often quickly change 
between them within a terminal.


The Qt tool itself could be written using the internal Qt bootstrap library.


What do you think?

Folks from the Oslo discussion: anything I missed?


Simon