Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Qt Creator include paths on Windows
Jeanne-Kamikaze last edited by
I am trying to build a simple project in Qt Creator under Windows using the 5.1 opengl/msvc 2012 64-bit release, but it seems that INCLUDEPATH/DEPENDPATH are not working properly. For example, if I edit the project's .pro file and add
INCLUDEPATH += foo
DEPENDPATH += foo
and then build the project, there is no "foo" in the compiler output, and then any source files including any files in that 'foo' directory or any of its sub-directories fail to compile.
Could anyone provide any light on this?
welcome to devnet
Probably you need to trigger a qmake run. Go onto the project in the project window. Do a right click and choose "run qmake" and try to build again. After running qmake you can check the makefile if the folder name is taken over.
Jeanne-Kamikaze last edited by
Thanks for the fast reply, I got that working by running qmake as you said. It looked rather confusing because Qt Creator would "parse" and "evaluate" the .qmake file after being modified, but it wouldn't work unless I manually "ran qmake".
Unfortunately, it is still a good bet to recommend running qmake.
AFAIK there is also a "qmake" in creator integrated which apparently does not have the full potential as qmake yet. Duality is always a trigger for those kind of things. Probably the priorities are somewhere else respectively they are hard to track,
The latter discussion is more philosophic without knowning any details.
koahnig: Unfortunately some duality is unavoidable here since qmake and creator are trying to get different results from the same input.
Basically qmake is interested in exact results: In the current configuration this-and-that is to be built. Creator on the other hand is more interested in the "big picture": This list of files are part of the project in general.
So qmake does not care at all about windows-only files when building on linux, while creator wants to have those in the list of files belonging to the project. After all you want to see the windows code when looking for symbols, etc., even when working on Linux.
But even in spite of that: The parser code is nowadays shared between qmake and creator afaik. It is just that sometimes creator does not notice changes to the .pro-file in its "fuzzy mode" that are relevant in "exact mode" while building.
tobias: Thanks for correcting my understanding
I was under the impression that there is a "qmake" in creator which will take over eventually the external qmake actions.
From the outside seen it is a bit strange when an IDE saves a files (.pro) and does not trigger the required action (running an external or internal qmake process). Especially when the "evaluating" and "parsing" bar create the impression that all things required are done. Apparently the right things are triggered, but just something is missed.
Knowing that things are certainly getting sometimes more complex then seen from the outside does not make it more understandable.
As stated above it is always a good bet to recommend rerunning qmake when something does not do as expected. I got certain work patterns where I simply slip in a rerun qmake before starting the build process. Unfortunately, I could not reproduce when trying to narrow it down.
By stating so, I am NOT definite that it is really a direct qmake issue rather than a mingw-make or makefile issue in my case. To me it looks more like the makefile or its scanning is in error for most of my issues. However, I know that the rerun of qmake will save me quite a bit of time.