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

[Oswald Buddenhagen]

On Tue, Jan 20, 2015 at 06:59:46PM +0100, Kevin Kofler wrote:
> Oswald Buddenhagen wrote:
> > 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).
> 
> We do that. The problem is that some upstreams are not cooperative and blame 
> us for "breaking" Qt instead, most notably the Qt Project itself (see also 
> Thiago's replies), which is upstream for more than just core Qt.
> 
if we make it official by providing packaging guidelines, you can stick
it right into their faces.

> > also consider that this problem is "a tad" bigger than just qt. you
> > really need to define a cross-distro standard anyway.
> 
> The cross-distro standard is normally what upstream ships. The problems only 
> come up when we have to rename it downstream.
> 
of course. but unifying the upstreams can be considered a goal in
itself, and the intiative for that would have to come from an alliance
of downstreams. but whatever - not my problem.

> > but as others pointed out, the name clash of qmake from qt4 and qt5 is
> > advantageous in some porting scenarios.
> 
> The first step of porting needs to be to change the version of Qt used. This 
> is very commonly the case when porting to a new major version of a library.
> 
that's besides the point. the scenario eike pointed out is two-way
compatibility once the porting is done.

> > and in case of unified dispatchers like qtchooser (and lots of custom
> > scripts), divergence would be actively counter-productive.
> 
> How so? You could wrap both the -qt5 and -qt4 names, with wrappers using 
> different config files and/or different environment variables, and so select 
> both a default Qt 5 and a default Qt 4, or just choose on the command line 
> (e.g. qmake-qt5 -qt=debug). Trying to build Qt 5 code with your favorite Qt 
> 4 will not work, the selection ought to be separate.
> 
when the qt4 one is named qmake and the qt5 one qmake-qt5, things become
rather non-uniform. let's start with qtchooser: it would have to be
aliased as qmake-qt5 to be compatible with qt5 upstream (which would be
a dead alias for qt4), and it would still have to be aliased as qmake
(which might be dead for qt5, depending whether you want to deviate from
the qt5 guideline). and scripts are usually a mess, and supporting two
binary names would make it even worse.

of course these are arguably minor problems (even if some qt devs with
particularly strong finger memory will disagree), but then, your
problems as packagers are arguably minor, too.

therefore, i prefer not to change anything, especially considering the
cost of the upstream renaming itself.

On Tue, Jan 20, 2015 at 10:04:51AM -0800, Thiago Macieira wrote:
> On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote:
> > > 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.
> > 
> > In that case, nothing is going to change on our end either, I can
> > live with that (though I don't like the situation, for the reasons
> > explained above), but Thiago will not be happy.
> 
> I will be happy with the renaming provided that:
>
kevin meant that you would be unhappy with deprecating qtchooser as far
as distros are concerned, and staying with the status quo (i.e., distros
provide renamed aliases).