[Development] Co-installation & executable naming rules

[Lincoln Ramsay]

On 9/10/12 5:17 PM, Simon Hausmann wrote:
> 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.

At one time I had installations of Qt 2, 3, 4 and 5 on my machine. Yes, 
all in use at the same time.

Granted, that's not the case anymore but it's much easier to handle 
differences in products using the environment than it is when binaries 
have different names. Getting the environment right is easy. Getting 
your fingers to run different commands as you switch versions is hard.

People with an IDE don't care but any solution that integrates with an 
IDE will be transparent to them.

Distro packagers can't have two packages that create /usr/bin/qmake but 
they can create /usr/lib/qt[4|5]/bin/qmake and use a defaults system to 
make /usr/bin/qmake a symlink to one of those. Maybe even have 
/usr/bin/qt4-qmake and /usr/bin/qt5-qmake for people that don't want to 
screw with the PATH.

My fingers will run continue to run qmake, moc, uic, etc. so don't break 
that. I don't care if I have to set a PATH to get them.

-- 
Link