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

[Oswald Buddenhagen]

On Tue, Jan 20, 2015 at 01:55:41PM +0100, Kevin Kofler wrote:
> Some programs need adaptations to build on distros because they do not
> expect the binary names we ship.
> 
but that work has already been done, long ago. even adjusting it to qt6
at some point will be a rather trivial effort (and zero for you if you
bothered to upstream build system improvements that make upstream
packages work out of the box with packaged qt).

> > 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.
> 
> If upstream were to ship suffixed binaries such as qmake-qt5, it would do 2 
> things:
> 1. ensure that some distro won't come up with its own naming scheme, e.g.
>    qmake5, q5make, qt5-qmake, qmake_from_Qt_5 or whatever some packager can
>    dream up (if the official binaries are called "qmake-qt5" etc., there
>    will be no reason for a distro to use any of the other names),
>
but this is already the case, and has been since qt2. so that ship has
sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the
debian (?) guys made clear that they'll keep their qmake5 (?) scheme
anyway - they must, for compat reasons. so whatever we do is add-on only
anyway.

and if a *new* distro chooses *yet* another scheme ... well, shoot them.
i suggested that the qt project should publish packaging guidelines, so
there would be no need to become homocidal.

also consider that this problem is "a tad" bigger than just qt. you
really need to define a cross-distro standard anyway.

> 2. ensure that programs/scripts do not have to handle both renamed and
>    unrenamed binaries, because ALL Qt binaries (from ALL distros and from
>    upstream) should then be using the renamed ones (as there would be no
>    reason to rename it back to "qmake", at most to ship both variants for
>    compatibility).
> 
but as others pointed out, the name clash of qmake from qt4 and qt5 is
advantageous in some porting scenarios. and in case of unified
dispatchers like qtchooser (and lots of custom scripts), divergence
would be actively counter-productive.

given that the problems specific to distros have been adequately solved
(even if you find that hacky - which it certainly is in case of badly
written build systems), i don't see why we should bother changing
anything at this point.