[Development] Co-installation & library naming rules

[Saether Jan-Arve]

> -----Original Message-----
> From: development-bounces+jan-arve.saether=digia.com at qt-project.org
> [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org]
> On Behalf Of Simon Hausmann
> Sent: 18. oktober 2012 16:42
> To: development at qt-project.org
> Cc: Thiago Macieira
> Subject: Re: [Development] Co-installation & library naming rules
> 
> On Thursday, October 11, 2012 04:11:10 PM Thiago Macieira wrote:
> > On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen
> wrote:
> > > On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote:
> > > > Considering all the changes I am proposing do NOT harm any of the
> > > > people that build from sources,
> > >
> > > they *do* harm. i positively do *not* want to use qmake-qt5 just
> > > because it's the least evil for linux package users.
> >
> > That's the very most important change that needs to be done: renaming
> qmake.
> > All the other tools could be separated elsewhere, the libs could be
> in
> > different dirs. But qmake is the one tool run directly by users, the
> > one tool that Qt Creator asks users to locate.
> >
> > It needs to be renamed..
> >
> > If you don't want to make it the default, then at the very least we
> > need to add the option to our configure script to force the renaming.
> > We need to adapt our buildsystem to creating the renamed tool. This
> is
> > not debatable... we simply need to do it in Qt.
> >
> > I don't want distribution packagers choosing different methods: I
> want
> > them all to have the same solution, the one solution that will be
> > recommended to LSB 5.0, the one solution that the helpful people in
> > #qt, interest@ and other discussion channels will need to know.
> >
> > In other words, the renaming will be the de-facto default for
> everyone
> > using Linux.
> >
> > Why the hell shouldn't it be the de jure default too?
> 
> As it turns out, we may not need to rename it. Let's just take it out
> of /usr/bin, along with the other binaries. Let's put them into
> /usr/lib/qt5/libexec for example. (Heck, distros can tweak that via
> configure if they want to).
> 
> If instead we had a proper equivalent of "qset" as a real program that
> would allow changing between different Qt versions easily, then it
> wouldn't matter where that qmake binary is. If it's in
> $HOME/dev/qt5/qtbase/bin or in /usr/lib/qt5/libexec/ - I would use "qt
> qmake" and depending on what my current Qt version is, it would call
> the right qmake binary.
+1
It should also be possible to just use "qmake" (instead of "qt qmake") 
by using aliases. (But that's just sugar on top)

Jan Arve