[Development] renaming qmake for everyone (was: Re: Co-installation & library naming rules=)

[Oswald Buddenhagen]

[changed the subject to get some attention ... from a quick survey i
don't have the impression that many people grasp that this thread is
very much relevant for them.]

On Thu, Oct 11, 2012 at 04:11:10PM -0700, 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?

after having seen your first patches and thinking some more about the
consequences, i'm more than ever convinced that this initiative is
entirely misguided.

the basic point is that you are actively breaking backwards
compatibility.
before this change, we could simply tell people "change your PATH, qmake
&& make". heck, we could even tell them "run $qtdir/bin/qmake && make".
this is even emphasized by your own initiative to rename quick1 back to
declarative.

with this change it gets nasty:
- in the easiest case people use qmake, and it covers all their needs.
  the one thing they need to remember is using qmake5 instead of qmake -
  this is annoying and leads to asymmetries when major versions are not
  the only reason for separation (think minor versions and different
  build configurations), but it's kinda bearable.
- the next case is people using tools which are not covered by qmake.
  think lupdate, lrelease, xmlpatterns. this needs adjustment.
- the next case is not even using qmake. now everything needs to be
  adjusted - all tool and library names.
one can argue that this is a one-time change. but reality shows that it
isn't for the transition phase during the next months: creator supports
both versions, and it's probably not going to be the only such project.
so we get lots of conditionals in the project files.

now let's look at the problem it solves:
- in theory, linux distributors can now use -prefix /usr and don't need
  to rename any build-related things on their own, and thus we set the
  ultimate standard upstream
- in reality, some distributors will still rename linguist and other
  "end user tools", as they have "no-conflict" policies, so "everybody
  does the same" remains a blue-sky dream.

as you wrote yourself above, distributors can easily put the qt versions
in different places (like they do so far), and it doesn't cause much
trouble (see my previous mails). however, you are arguing that if
nothing else, qmake still needs to be renamed. i think that's just
wrong: to not break the path-based setups, it must be only *aliased*,
and that happens outside the qt installation directory. therefore it is
outside the scope of qt's repositories.