Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Error while parsing .pro file. Giving Up.
NickM last edited by
I know this question has been asked a few times here, but I've yet to find a solution that applies to me. Basically, when I add a new project to QT, I get the following General message:
Running Windows Runtime device detection.
No winrtrunner.exe found.
C:/Qt/Qt5.12.1/5.12.1/mingw73_64/mkspecs/features/toolchain.prf(76): Variable QMAKE_CXX.COMPILER_MACROS is not defined.
Project ERROR: failed to parse default search paths from compiler output
Error while parsing file C:\Qt\Test\TestProj\TestProj.pro. Giving up.
Then, when I try to add a file to this project, it is disabled. eg: Right clicking on the project, all the "add" options are greyed out. Alternatively, making a new .cpp or .h file, the dropdown menu to select which project I want to add this file to is disabled as part of the File>>New File or Project sequence.
Essentially I can't do anything. Now, if the project I added was an empty Qmake project, if I populate the .pro file with the following generic stuff:
TEMPLATE = app
TARGET = test
QT = core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
Then I save and close the project, and reopen, everything works as it should. I can add files.
But if I make a QT Console application where the .pro file is populated from the template, then it just flat-out doesn't work. No amount of opening or closing changes anything. The message shown above persists.
Does anybody know what causes this? It's really irritating.
Some useful information/things I've tried so far:
I'm currently running QTCreator 4.8.1, as part of a QT 5.12.1 installation. I had the same issue with newer and older installations on this same computer. I can't remember the older one, but I tried 5.12.6 as the newer one. I'm currently using the Desktop QT 5.12.1 MinGW compiler (64-bit) on a Windows 10 64bit system. I've installed an identical version on a laptop (also windows 10, 64bit) and I don't get this issue. I've had a quick look at our company's anti-virus and firewall and I don't see any QT related stuff in quarantine. Also, for what it's worth, I have a few instances of visual studio installed (2013 and 2019, neither with the QT add-in) - possibly some conflict there.
There's a strong chance I'm doing something dumb here. I'm pretty new to QT.
dawnhowe-sync last edited by
@NickM I had exactly the same problem you did. I think the problem is an interaction with Qt and VS2017/VS2019 being installed (or recently upgraded). We were having the same problem building on Windows 10. Our project is compiling our Qt project with both Visual Studio 2019 (using the MSVC compiler), and with Qt 5.12.7 (using a MinGW 64bit compiler).
We had a pretty big refactor, so I deleted build directories and *pro.user files. Then I had the same thing happen to our Qt projects. I also created a default project, closed Qt and when I restarted it, I could not parse the *.pro file with the same error you saw. After some investigation, I restored .qmake.stash files that I had deleted (from the Recycle Bin) and the build started working again.
What I pieced out is that Qt depends on qmake running (This bug was supposed to be fixed: https://bugreports.qt.io/browse/QTBUG-60059, but I decided to focus on qmake). After a bunch of trial and error (without a good explanation of why it work), I found a solution.
I got this procedure to work a few times.
- delete any build artifacts and *pro.user file
- open project and configure it for MinGW 64bit.
- get the error
- to build->run qmake (You can watch the Compile output to see that it runs properly)
- click on "File"->Close Project
- click on "Files"->recent projects and pick your project to open again.
- Now it's fixed!
- Be safe and do a build.
Also, as long as you don't blow away all the build artifacts while QtCreator is closed, opening the project seems to work find. You can blow away all the artifacts while QtCreator is open, and then rebuild before closing and everthing works ok.