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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
