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

Kevin Kofler kevin.kofler at chello.at
Sun Jan 18 06:56:28 CET 2015


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.

(*) I am assuming here that the build system is not qmake itself. If it is,
    NONE of the existing solutions manage to solve this problem
    automatically, neither our suffixed binaries, nor qtchooser, nor
    anything else that I have seen. It would probably need something like
    QT_VERSION=5 at the beginning of the .pro file, and then logic in qmake
    to delegate to the correct qmake-qt$QT_VERSION. But of course, that
    would not fix the problem for all the existing .pro files that do not
    have such a key.

And by the way, even the conceptual thing is also quite practical. I have 
all of qt3-devel, qt(4)-devel and qt5-*-devel installed, and I can build 
programs with all three versions without having to reconfigure my system in 
any way.

        Kevin Kofler




More information about the Development mailing list