[Development] Co-installation & executable naming rules

[shane.kearns at accenture.com]

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

This is similar to the approach that java took.
There you'd use:
"javac <file>" to compile using the default JDK
"javac -version 1.5.33 <file>" to compile using the 1.5.33 JDK

The javac in the path was a thin wrapper that checked for the -version argument and forwarded to the appropriate version.

I'd prefer qmake to work like that, rather than needing "qt qmake"
This would mean we'd need to find and reserve a command line argument for selecting qt version that is available in all the qt tools that would be installed in the path usually.

Another thing you need to consider is named versions.
For example I might have "5.0.0" and "5.0.0-blackberry" co-installed.
I think Qt Creator handles this just fine, but the "qt --5" examples above look like it wasn't considered.

Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com