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

Konstantin Ritt ritt.ks at gmail.com
Sun Jan 18 18:08:24 CET 2015


2015-01-18 9:56 GMT+04:00 Kevin Kofler <kevin.kofler at chello.at>:

> Thiago Macieira wrote:
> > Please list them again, so we can address them. The one I can remember
> now
> > is the default config file for multilib, which is fixable by using
> > alternative. Multilib development is covering the sun with a sieve, so
> > pardon me if I don't give it too high a priority.
>
> The issues are:
> * conceptual: Choosing a Qt version ought to be:
>   - the job of the software being built (i.e., its build system(*)), whose
>     developer knows what version of Qt is needed, not the job of the user
>     building the software. This is a fundamental conceptual disagreement.
>     The goal of our setup has always been that the user should NOT have to
>     do anything other than (e.g.) cmake . ; make ; make install to build
>     software, and the software should select its Qt by itself,
>   - a setting specific to the program being built and not to the user
>     account or even the shell environment.
> * practical: How do you propose that, say, an autotools setup (let's skip
>   CMake, where the *Config.cmake files are doing wonders) checks whether
>   "moc -qt5" will work as advertised? (It could get any old "moc" binary
>   without a qtchooser wrapper.) With the suffixed binary, a simple
>   AC_CHECK_TOOL (check whether moc-qt5 exists in the PATH) does the job.
> (If
>   you go the "run qmake, use it to get the path to the unwrapped/unsuffixed
>   moc" road, same question with "qmake -qt5" vs. "qmake-qt5".) The same
> goes
>   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.


> qmake-qt5 -qt 5.1


Or maybe qmake-qt5 -qt qt-5.1 (can not think of more 'qt'-s, sorry).


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


More information about the Development mailing list