Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Creator not finding qmake.exe even though it is in PATH



  • Hello,

    I'm wondering whether I should submit a bug report for an issue I've seen in Windows 7 using the MSVC2010 compiler toolchain. I've built 4.8.2 from source without any issue except that I have to disable phonon support in order for designer.exe to run. The command I used was

    configure -debug-and-release -opensource -no-phonon

    with QMAKESPEC set in my environment variables to win32-msvc2010. It builds and the demos run fine. I also built Qt Creator 2.5.0 from source using the version 4.8.2 Qt tools. It also seems to run fine. All of the builds were done using the 32-bit toolchain (even though I am using Windows 7 x64) due to some binary dependencies of one of my projects. Even though I have qmake.exe in my PATH environment variable, Creator doesn't find it. I know that my PATH is correct because the command `where qmake.exe' executed in a command window returns the correct path to qmake.exe. This is not a huge issue, since I just pointed Creator to the qmake executable and it seems to build projects in both debug and release modes just fine, but I know that with my previous Qt version (which was 4.7.something, and also built from source), Creator detected it and listed it as 'Qt in PATH'.

    Has anyone else seen this issue? Am I doing something subtly wrong?

    Thanks,
    Hunter



  • Hello.
    I had similar problem with Qt installed without using Qt SDK Maintain Tool. The best solution I've found is to go to "C:\Users%username%\AppData\Roaming\Nokia" directory and remove (or posibly change, but I've always removed it) file qtversion.xml.



  • Simply deleting that file did the trick. Thank you.

    -Hunter



  • thanks, i had same problem


  • Moderators

    Yeah, this is most likely a bit unintuitive.

    We only check for "Qt in PATH" once and then stick with what we found. This is to avoid the Qt version switching whenever somebody manages to move another Qt into his PATH. That could break existing projects.

    Our solution is not nice, but at least it keeps projects working. If somebody has a better idea I would love to hear it.

    PS: "Qt in PATH" should be a "manual Qt version", so you should be able to change it.



  • Hi Tobias,

    Thanks for the explanation. Yes, it is listed as a "manual" version as you said. To be precise, it is listed with the version number, as "Qt 4.8.2 in PATH (4.8.2)".

    As a question/suggestion, would it be possible to have Creator search on startup (or perhaps have a button in the Qt Versions tab that initiates a search) so that any and all Qt versions in the path are found and added? This doesn't mean that versions which are no longer in the PATH have to be deleted, though, in case they are still present but simply no longer in PATH. I suppose another interesting side effect of the "search once" design is that if I were to remove my Qt 4.8.2 folder from my path, it will still be called "Qt 4.8.2 in PATH" despite no longer being in the PATH.

    While I agree it woudl be bad if adding a new Qt version would replace the old one and potentially break existing projects, is there a significant issue with having multiple versions (built from source) detected and added automatically?

    Please note that I'm not trying to stir anything up here or saying that it needs to be changed from how it is now. It's certainly usable now -- I was just afraid I had done something wrong.

    Best,
    Hunter


  • Moderators

    We want creator to start up fast, so we can not search around the disk extensively (especially on windows;-). Unfortunately the only reliable way of finding all installed Qts is to look into each and every directory on the host... which is way to expensive.

    Qt versions installed by the SDK are registered with the creator the SDK knows about. So those should show up fine. Custom built Qt versions are tricky though.

    I don't think that having several Qt versions in PATH at the same time is a good idea: If an rebuild fails for the first one in the PATH you might end up calling programs installed by the second Qt in your PATH. That can lead to all kind of strange effects.


Log in to reply