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

Konstantin Ritt ritt.ks at gmail.com
Sun Jan 18 19:39:32 CET 2015


2015-01-18 22:02 GMT+04:00 Lisandro Damián Nicanor Pérez <
perezmeyer at gmail.com>:

> On Sunday 18 January 2015 21:08:24 Konstantin Ritt wrote:
> [snip]
> > >   for pretty much ANY build system out there.
> >
> > There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> > internal build tools invoked by qmake and thus they should normally
> reside
> > in libexec dir (or you may query qmake for its specific libexec dir path
> to
> > invoke them manually) -- just like GCC's cc1 or fixincl.
> > So the question is about "qmake -qt5" vs. "qmake-qt5" only. Here, if
> qmake
> > is a "smart" wrapper, its usage is similar to pkg-config: one may query a
> > list of installed packages, obtain their properties, or invoke a command
> on
> > a tool itself - the only difference is that it lists Qt configurations
> > instead of packages.
>
> No, there's also qdbus for instance. We in Debian had some problems when
> users
> managed to get a qt4 program using qt5's qdbus by setting qtchooser's
> default
> at qt5. The good side of this: it turned out to be a bug in qt5's qdbus
> which
> got fixed and then it simply worked, but if at some point qt4's and qt5's
> version of qdbus behave differently then chances are that we are going to
> see
> more bugs :)
>
> I don't remeber if there are more executables in the same position as qdbus
> (ie, called at runtime) but as long as we have Qt4 as default (as we do by
> using qtchooser) more of this problems might arise.
>
> Now if there is a workaround for this I would like to know it, as it will
> sure
> be handy in the near future.
>

It is a run-time dependency, which is a bit different question/issue. I'd
say it should be
provided by the system-default Qt to be used by the other tools (i.e. it
would be a x86_64 binary
in a multilib environment); and if that doesn't work, then a respective
issue should be prioritized.
For example, there is no sense in having a Qt Creator build per Qt
configuration - we simply use one provided by the system
(except of those of us who builds it from sources :P).


Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150118/a977d4bf/attachment.html>


More information about the Development mailing list