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

[Oswald Buddenhagen]

On Mon, Jan 19, 2015 at 07:30:46PM -0800, Thiago Macieira wrote:
> On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote:
> > Oswald Buddenhagen wrote:
> > > 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.
> > 
> > The thing is, we asked for something that fulfills distro's needs.
> > You shot that down and instead got Thiago to implement something
> > different. And now you say yourself that it is not what was asked
> > for.
> 
> I'm agreeing with Kevin here.  [...]
> 
> So no, don't tell us qtchooser is not meant to solve distros'
> problems. It's meant exactly for them.
> 
but i do. my purpose was to keep the imo (slightly) detrimental change
out of qt, and enabling our developer use case to be convenient. i never
considered the distro case relevant as such - i demonstrated why it is a
non-issue back then, and i did it again in my previous mail. there is
simply no problem that needs solving upstream. the fact that fedora
successfully ships qt5 packages proves this.

> > > build systems which target specific (major) qt versions are simply
> > > out of scope.
> > 
> > Says who?
> 
says me. and in case you already forgot the context: we're talking about
the scope of qtchooser at this point.

of course one can insist on making qtchooser (used explicitly, not
relying on aliasing) the only blessed interface for build systems, but
i think it's obvious that this idea is a non-starter.

> To be clear: Ossi was talking about development files and tools, not
> about the libraries. And also note he's referring to another self-made
> problem of not allowing binaries outside of /usr/bin.
> 
correct. there is no problem at all if you put the binaries of each qt
build into an own directory (a subdirectory of qt's libexec would be
probably right, even if it sounds backwards at first) and then alias
them from /usr/bin with suffixes.

> > > 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.
> > 
> > Now this is really funny. We wanted to do the renaming upstream. You
> > were one of those people who shot it down.
>
correct.

> > Now you are saying we should just do it downstream.
>
no, i already said it back then. and your (or maybe rex') argument was
- literally - that you can't do it, because distros won't agree among
themselves. so upstream mandating a solution by renaming the binaries
itself is necessary. hilarious. as if that would keep anyone from doing
what they want anyway.

> > > i consider this discussion closed, including for qt6.
> 
> You don't get to decide that. First of all, you can't tell what the 
> environment for Qt 6 will be.
> 
the assumption is obviously that the "environment" won't change. i don't
see how it could, and what i've seen so far doesn't suggest that i'm
overly optimistic with that prediction.