[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Oswald Buddenhagen]

consider this a meta-reply to the entire thread.

On Sat, Jan 17, 2015 at 11:46:58PM +0100, Kevin Kofler wrote:
> Thiago Macieira wrote:
> > packagers, like we did in the past for qtchooser (a solution
> > designed for distro's needs).
> 
> Hahaha, that's a good one!
> 
> Qtchooser is designed completely PAST distros' needs and entirely
> useless for distros. What we actually asked for (and have always been
> shipping, and at least in Fedora, still ship for Qt 5) is suffixed
> binaries.
>
correct. as far as i'm concerned, the purpose of qtchooser is to be a
frontend tool which targets developers working with multiple qt
versions, regardless whether these versions come from distro packages or
own builds. build systems which target specific (major) qt versions are
simply out of scope.

your problem is a self-made one: the attempt to co-install major
versions of everything. this is a linux distro specific problem, and
demanding x-platform upstreams to accept trade-offs to adjust to it is
*unreasonable*.

now, you will say that most users under linux use qt via distro
packages. that's right. and you know what? it's *your* task to make it
work for them.

if upstreams of qt-using applications choose to support distro-packaged
qt (via having preference lists of suffixed qmakes, for example), that's
a perfectly reasonable thing to do. if distros among themselves want to
standardize on a pattern to ease this, i'm all for it. it's still not
something *we* (qt upstream) need to be concerned with.

the rest should be considered non-normative, to use RFC speak. it's
mostly re-iterating already made points from 2011:

- for build systems based on cmake this whole discussion is irrelevant,
  because they make use of the module registration system via *Config
  files, which is the *right* thing to do. this is the case because you
  are right that the build system should choose which qt version [range]
  it wants to use. only your conclusion that this should happen via the
  name of the qmake binary (or even other tools) is a tad narrow-minded
  - even multi-arch shows that your approach is too limited.

- build systems which use qt tools without querying qmake (or cmake) for
  their location are *broken*.

- for build systems based on qmake, there isn't a *good* way to choose
  the right version, simply because qmake is not a generic build tool,
  but bound to a particular qt version.
  one can choose to make a configure script around the qmake build
  system, or one can delegate it to the user. the conventional way to do
  the latter would be setting PATH. qtchooser is just a nicer way to do
  the same (on the command line - scripted use is not really in scope,
  as i wrote above).
  the upshot is that it doesn't matter much whether the build system
  uses qmake as the workhorse or not, because it needs qmake as a
  "frontend" anyway.
  
  note that this poses no problem for packaged qt-using apps/libs,
  because you can instruct their build to use a specific qt easily
  (e.g., via the environment or configure options).

  however, we *can* have a distro-friendly qt5-config tool which
  replaces qmake -query for configuring external build systems, as
  adding this doesn't break any existing workflows. in fact, in qt6
  there won't be qmake any more (one way or another), so we should add a
  dedicated tool already to ensure a smoother transition.

- for "frontend" applications like designer and linguist the same
  applies as to qmake. so distros may choose to provide aliases to them
  in $PATH, like for qmake.

- for "backend" tools like qdbus, you can either a) assume backwards
  compatibility and rely on PATH or b) ask qmake for the correct paths
  (at build time, obviously, and embed the result in the
  binaries/scripts). this also applies to attempts to script "frontend"
  apps, like the mentioned assistant case.

i consider this discussion closed, including for qt6.