[Development] Co-installation & executable naming rules

[Simon Hausmann]

On Tuesday, October 09, 2012 09:07:10 AM Lincoln Ramsay wrote:
> On 08/10/12 22:58, Simon Hausmann wrote:
> > 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.).
> 
> I hope this is in addition to putting the binaries in a versioned
> directory with the _same names_ as they have always had?

I'm not 100% sure I understand what you mean, but let me re-phrase the 
intention of the proposal:

The name binaries in the file system changes _only_ per major version of Qt 
(i.e. qt5-moc, qt6-moc), no matter how funkily a developer configures qtbase.

Simon
 
> I've worked with multiple simultaneous builds for years, covering
> multiple major versions and the only thing that kept things sane was
> setting up the environment per-shell. Keeping track of the different
> configure options required through those versions was bad enough.
> Tracking different binary names across different builds would be
> terrible (not to mention making re-use of command history really painful).