On Thu, 26 Oct 2017 10:08:29 -0500 Frank Miller <cfrankmil...@gmail.com> wrote:
> I'm not much of a qmake user so I don't really know what I'm doing. I'm > building qt-creator against a build of qt installed in $prefix and in > order to get it to work I had to call qmake like this: > > $prefix/bin/qmake -r \ > QMAKE_CFLAGS_RELEASE="-I$prefix/include" \ > QMAKE_CXXFLAGS_RELEASE="-I$prefix/include" \ > QMAKE_LFLAGS_RELEASE="-L$prefix/lib" \ > $srcDir If you had to do that, then your Qt installation is broken. Calling qmake should work out of the box, with no such constructs necessary (in fact, as you have noticed, they overwrite lots of predefined stuff that might even be necessary). > > Yes, you are right. It seems commit 4b8564cb42 introduced this issue. > > Note that that commit is also conceptually wrong, as the target system > > is relevant for the choice which functionality to include, not the host. > > For instance, if you built Creator with mingw on Linux (which we don't > > do), then MSVC support would be missing from the resulting binaries. > > Any chance for you to push it to gerrit? > > I have never used gerrit before but I would be willing. This should have the necessary information: https://wiki.qt.io/Gerrit_Introduction The procedure is less daunting than it looks. If you decide against it after all, please let me know. > How does one determine the target system? Using the Q_OS_* macros, as it was before the patch. (Note: It turns out that the HostOsInfo class is badly misnamed, as it also uses these macros internally. The author simply assumed that Qt Creator would never get cross-compiled. But that's not relevant to our problem here.) In fact, simply reverting the patch would be perfectly okay, except that it doesn't apply anymore, because other things have changed in between. Christian _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
