On Sunday 18 January 2015 23:13:30 Kevin Kofler wrote: > Thiago Macieira wrote: > > This, Qt 3 software do "qmake". Qt 4 software do "qmake -v" to determine > > which version it is: if they found Qt 3, they try "qmake-qt4". All of this > > is already implemented and was in place before 2012. > > Why would they need to try running anything? Just use qmake-qt4 if it > exists, and qmake otherwise. The same works with our qmake-qt5.
Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't renamed. Software is supposed to work with the official version too and there are 9 years of history of us releasing "qmake". Therefore, that buildsystem needs to try qmake alone. > > As for Qt 5 software, they have three choices: > > > > Option A: Qt 5 software do "qmake -qt5" and the result is one of two > > > > options: > > 1) qmake is qtchooser, so it works > > 2) qmake is not qtchooser, so it will return an error, in which case they > > can conclude Qt 5 is not installed > > > > Option B: Qt 5 software do: "qtchooser -qt5 -print-env" and parse the > > result. Here it is: > > QT_SELECT="5" > > QTTOOLDIR="/home/thiago/obj/qt/qt5/qtbase/bin" > > QTLIBDIR="/home/thiago/obj/qt/qt5/qtbase/lib" > > This means they need to actually run the executables, whereas with the > suffixed binaries, they need to check for their existence. And in practice, > portable programs also need to check for qmake-qt5 ANYWAY because it is > already in widespread use (at least Fedora, RHEL, CentOS, Scientific Linux, > etc., maybe also others, I haven't checked lately what other distributions > ship), and there is no way this is going to change in the 10 years of life > time of RHEL 7. I'm ignoring qmake-qt5 because it's totally non-standard. You guys created the problem, you guys can pick up the pieces. If buildsystems don't work with your modifications, it's your problem, not ours. We had a solution you chose not to adopt. But yes, they need to run things. How is that different from running pkg-config? Or running mysql_config? > > Option C: Qt 5 software doesn't bother trying to run qmake and simply > > assumes the tools are in $PATH. > > Those programs are what I call "broken" and curse at whenever I see them > (and then submit a patch checking for qmake-qt5 to; most upstreams other > than you (Qt Project) are receptive to such patches). In other words, instead of fixing what you broke in one place, you send workarounds to everyone else (N places). > > Is this autotools-based setup a unit test for moc? No? Then why is it > > trying to verify that it works as advertised? How can you tell what is > > "works as advertised"? > > > > The only way to verify that it works is to actually run it and compile the > > result against the qobjectdefs.h header. If there's a mismatch, it will > > either fail to compile or link. Other than that, there's nothing you can > > do to verify that it works as advertised. > > If the binary is called "moc-qt5", it is safe to assume that it is a moc > from Qt 5. If the binary is called just "moc", there is indeed no telling > whether it will accept a "-qt5" argument without trying to run it with that > argument. That was my whole point. That check is irrelevant. You either run a full path to moc, which you obtained from qtchooser or qmake, or you run "moc -qt5". Any of those three are going to successfully run the Qt 5 moc if it's there or it's going to fail. > > Software that chose option C runs "moc -qt5" and, just like option A for > > > > qmake, it will: > > 1) moc is qtchooser, so it works > > 2) moc is not qtchooser, so it will stop with an error, in which case you > > can conclude there's no Qt 5 installed. > > And that conclusion will be wrong on any system that does NOT use qtchooser. Which should be zero. All systems should use qtchooser, except Windows. > There will always be systems with Qt 5 and without qtchooser (even if > Fedora and RHEL were to adopt it, which is extremely unlikely to happen > too, especially for existing RHEL releases). Qtchooser is not even part of > Qt, so people building Qt from source will by default end up without it. > And distributions shipping only Qt 5 will also likely not want to bother > with qtchooser. If PATH was explicitly set to /usr/lib64/qt5/bin:$PATH or > if the Qt 5 binaries are symlinked directly into /usr/bin, moc is not > qtchooser, but running it without the "-qt5" flag would work. We can easily add it to Qt if that's the problem. And like I said, Fedora's and RHEL's refusal to follow the recommendation is their own problem. You get to pick the pieces from what you broke. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development