Qt Creator produces "No such file or directory" error with existing file

[Coolname007]

Hello.
I am having an issue when attempting to compile a project in Qt Creator. The error is:



No such file or directory.


but the weird thing is the file DOES exist, and at the exact same location the #include statement in my header file says its at.

Originally, I thought it was because I had not added the file being included to my project. But I already tried adding the file to my project and attempted to compile it again,
but I still got the same error. I even went as far as looking at the generated Makefile.Debug file Qt Creator created, and checked the rule for the file it was complaining about,
but that also is correct, so i don't know what the deal is.

Any ideas?

If you need any more info, just ask.

Thanks.

[d_stranz]

Have you told Qt Creator to look in the directory where your file is? Is it a problem with #include using "" vs. <>?

I'm not a Qt Creator user, but similar problems occur in any build environment. The compilers only look where they are told to look, and even if your file is in the place you think it should be, the compiler has to know that too.

[Coolname007]

Have you told Qt Creator to look in the directory where your file is? Is it a problem with #include using "" vs. <>?

I'm not a Qt Creator user, but similar problems occur in any build environment. The compilers only look where they are told to look, and even if your file is in the place you think it should be, the compiler has to know that too.
Well, since the file is located in a directory relative to the current directory (i.e. a subdirectory of the current directory of a header file which includes the problem header), I'm using #include with the "" syntax, and I'm definitely specifying the right file path. Pressing Ctrl + clicking the file path to the problem header in the #include statement opens up the problem header file, so that's how I know it is correct. That combined with the fact that I have included the same header file that includes the one that is creating the problem now in a different project, and that project compiled fine.
As for telling Qt Creator to look in the directory where my file is, I have tried added the following line of code to my project (.pro) file:



INCLUDEPATH += $$PWD

The INCLUDEPATH is a qmake variable which specifies the #include directories which should be searched when compiling the project, and PWD is a qmake variable which specifies the full path leading to the directory containing the current file being parsed. So basically I told it took it to look in the project directory for the header files, but it still produces that error. Of course, I'm not sure, if it searches the subdirectories of that directory or not. If not, then that explains it... I guess I'll try adding the subdirectories next to the INCLUDEPATH variable.

[wysota]

Pressing Ctrl + clicking the file path to the problem header in the #include statement opens up the problem header file, so that's how I know it is correct.
No. It only means QtCreator knows where to find a file with such name. It doesn't mean your compiler is able to find it.


That combined with the fact that I have included the same header file that includes the one that is creating the problem now in a different project, and that project compiled fine.
Which only tells us there is a problem with your project file.


The INCLUDEPATH is a qmake variable which specifies the #include directories which should be searched when compiling the project, and PWD is a qmake variable which specifies the full path leading to the directory containing the current file being parsed.
... which is the .pr{o,i,f} file.


So basically I told it took it to look in the project directory for the header files
Does the "missing" header file reside in the same directory as the .pro file?


Of course, I'm not sure, if it searches the subdirectories of that directory or not.
Of course not.

[Coolname007]

No. It only means QtCreator knows where to find a file with such name. It doesn't mean your compiler is able to find it.

Well, if Qt Creator knows where to find the file, and Qt Creator is the one that starts the compiler, then I would argue that Qt Creator should pass on that information to the compiler,
since the user doesn't run the compiler directly when using the Qt Creator IDE. Also, I see a flaw in your reasoning in that even if Qt Creator requires using the INCLUDEPATH variable
to explicitly specify the directories of each header file, outside of the #include declarations (which already includes that information, from which both Qt Creator and the preprocessor ought to be able to deduce
the location of each file, without the need for any extra information in the .pro file), in my case, even using INCLUDEPATH += PATH_TO_PROBLEM_FILE_DIRECTORY did not fix the problem. Therefore, there
must be a bug in the way Qt Creator passes on the information to the mingw32-make.exe utility, or else there wouldn't be a problem now, would there? :D


Which only tells us there is a problem with your project file.

Ok, well here is what my project file contains now (and the bug is still present):



INCLUDEPATH += C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value

SOURCES += \
C_html4_elements.cpp \
test.cpp \
C_html4_tags/C_html4_tags.cpp \
C_html4_tags/S_html_tag/C_html4_attributes/C_html4_attributes.cpp \
C_html4_tags/F_getHtmlCharCode/F_getHtmlCharCode.cpp \
C_element_formatter/C_tag_formatter/C_tag_formatter.cpp

HEADERS += \
C_html4_elements.h \
C_ENUM_element_converted_to_strings.h \
C_html_element/C_html_element.h \
C_element_formatter/C_tag_formatter/C_tag_formatter.h \
C_element_formatter/C_tag_formatter/C_rule/C_rule.h \
C_element_formatter/C_element_formatter.h

Note that "C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value" is the correct path to the problem header file from the current directory of the .pro file directory, and I no longer have the problem header
file added to my project tree (since I still got the error even with the file added).


... which is the .pr{o,i,f} file.

Right, I understand that.


Does the "missing" header file reside in the same directory as the .pro file?

No, it does not, like already mentioned in post #3. It is located in a subdirectory of the .pro file directory.



Of course not.
Thanks for clearing that up. I figured it probably didn't, but I wasn't sure, and note I've also tried:



INCLUDEPATH += $$PWD/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value

but I still got the same error.

[wysota]

Well, if Qt Creator knows where to find the file, and Qt Creator is the one that starts the compiler, then I would argue that Qt Creator should pass on that information to the compiler,
No, it shouldn't. QtCreator doesn't implement a compiler, it's just an advanced code editor. If you have two files called the same way then it often happens that Creator opens the wrong one. I don't think you'd want it to force the compiler to open a wrong file, would you?


since the user doesn't run the compiler directly when using the Qt Creator IDE.
It is the project file that ultimately drives the compiler. If you set it up incorrectly then it will work incorrectly.


Also, I see a flaw in your reasoning in that even if Qt Creator requires using the INCLUDEPATH variable
I never said QtCreator requires using INCLUDEPATH. I said the compiler toolchain does.


to explicitly specify the directories of each header file, outside of the #include declarations (which already includes that information
Which points me to a conclusion that your #include directive probably doesn't match your project settings.

in my case, even using INCLUDEPATH += PATH_TO_PROBLEM_FILE_DIRECTORY did not fix the problem.
Show us your #include directive and your exact INCLUDEPATH statement and tell us where your project fil resides.


Therefore, there
must be a bug in the way Qt Creator passes on the information to the mingw32-make.exe utility, or else there wouldn't be a problem now, would there? :D
Let's make a deal. If we manage to fix your problem and prove you there is no bug in "the way QtCreator passes information to make" then you'll donate not less than 100 EUR to QtCentre Foundation. Since as you said there must be a bug there, you don't risk anything. What do you say?

[Coolname007]

No, it shouldn't. QtCreator doesn't implement a compiler, it's just an advanced code editor. If you have two files called the same way then it often happens that Creator opens the wrong one. I don't think you'd want it to force the compiler to open a wrong file, would you?


It is the project file that ultimately drives the compiler. If you set it up incorrectly then it will work incorrectly.

And yet, I posted the complete project file in my last post...and did you see a problem in it??



I never said QtCreator requires using INCLUDEPATH. I said the compiler toolchain does.

Even that, I believe, is false, since I have built projects in Qt Creator before WITHOUT using the INCLUDEPATH variable (which is for qmake, btw, which is not a compiler...), and they worked and compiled just fine.



Which points me to a conclusion that your #include directive probably doesn't match your project settings.

Oh no?? Well, you see, the #include directive inside of every header or source file when using "" syntax refers to filepaths relative to the current directory of the file that contains it. Thus, when I wrote S_html_attr.h (located in C:/Users/MobileXMan/Documents/Programming_Projects/MAW/Modules/core/WebCoder_mod/modules/Html_coder/C_html4_coder/C_html4_elements/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr) which #include(s) S_html_attr_value.h (the problem file, located in C:/Users/MobileXMan/Documents/Programming_Projects/MAW/Modules/core/WebCoder_mod/modules/Html_coder/C_html4_coder/C_html4_elements/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value), the #include directive (which mingw32-make.exe now points to when producing the "No such file or directory error") inside S_html_attr.h is:



#include "S_html_attr_value/S_html_attr_value.h"




Show us your #include directive and your exact INCLUDEPATH statement and tell us where your project fil resides.

I just gave you the #include directive. And I already gave you the exact INCLUDEPATH statement in my last post. As for where my project file resides, the full filepath is:

C:/Users/MobileXMan/Documents/Programming_Projects/MAW/Modules/core/WebCoder_mod/modules/Html_coder/C_html4_coder/C_html4_elements



Let's make a deal. If we manage to fix your problem and prove you there is no bug in "the way QtCreator passes information to make" then you'll donate not less than 100 EUR to QtCentre Foundation. Since as you said there must be a bug there, you don't risk anything. What do you say?
Well, I dont think I'll agree to that deal (since I admit the problem could be somewhere else then where it looks like to me it is), but still, I could be right...

[wysota]

IMO should be either

INCLUDEPATH += $$PWD/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value

and


#include "S_html_attr_value.h"

or

INCLUDEPATH += $$PWD/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr

and


#include "S_html_attr_value/S_html_attr_value.h"


BTW, this:


Even that, I believe, is false, since I have built projects in Qt Creator before WITHOUT using the INCLUDEPATH variable (which is for qmake, btw, which is not a compiler...), and they worked and compiled just fine.

can be simply countered by the following trial: build the project without using QtCreator, with pure qmake && make call.

[Coolname007]

IMO should be either

INCLUDEPATH += $$PWD/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr/S_html_attr_value

and


#include "S_html_attr_value.h"

or

INCLUDEPATH += $$PWD/C_html4_tags/S_html_tag/C_html4_attributes/S_html_attr

and


#include "S_html_attr_value/S_html_attr_value.h"


BTW, this:



can be simply countered by the following trial: build the project without using QtCreator, with pure qmake && make call.
Hmm...I see. I wasn't aware that the INCLUDEPATH variable effects the #include declarations in that way.
In the documentation, on the "qmake Variable Reference" page, it says the following about the INCLUDEPATH variable:



This variable specifies the #include directories which should be searched when compiling the project.


I interpreted that to mean "it specifies the additional include directories which should be searched when compiling the project".
But now, I see, the emphasis should be on the #include part...

I posted about this same problem on the qtforum.org forums, and was basically just told the same thing.

However, while I was trying that, I discovered the real problem must have been in the .pro.user file I was using before, since when I re-setup the project for the Desktop platform (because I had opened it in my other OS - Ubuntu - installed as a dualboot on the same development computer, and the .pro.user settings were different), and the file was rewritten, I have now gotten past that error. So it seems it must have been an issue with the settings. I noticed that this time when I set it up, I chose the "None" option for the build configuration, instead of choosing "One Debug and One Release for each Qt version" like I had the last time (I believe...), so maybe that had something to do with it, I don't know. Anyway, its fixed now.

Thanks.

[wysota]

Hmm...I see. I wasn't aware that the INCLUDEPATH variable effects the #include declarations in that way.
INCLUDEPATH is no magic. It merely passes its contents to the compiler with the "-I" parameter.


I interpreted that to mean "it specifies the additional include directories which should be searched when compiling the project".
No, that is the work of DEPENDPATH. INCLUDEPATH is for includes only. But this has no influence on your current situation.


However, while I was trying that, I discovered the real problem must have been in the .pro.user file I was using before,
.pro.user file is not used for compilation. It merely contains QtCreator settings (of course including settings for running the compiler, but it only states which compiler to run (by passing options to qmake that parses the .pro file), not what directories it should search for include files). The .pro file controls compilation process.

[Coolname007]

INCLUDEPATH is no magic. It merely passes its contents to the compiler with the "-I" parameter.


No, that is the work of DEPENDPATH. INCLUDEPATH is for includes only. But this has no influence on your current situation.


.pro.user file is not used for compilation. It merely contains QtCreator settings (of course including settings for running the compiler, but it only states which compiler to run (by passing options to qmake that parses the .pro file), not what directories it should search for include files). The .pro file controls compilation process.
Well, how do you explain then that once the .pro.user file got rewritten and I removed the INCLUDEPATH statement from the .pro file, and tried to build, I'm no longer getting the "No such file or directory" error?

[wysota]

Well, how do you explain then that once the .pro.user file got rewritten and I removed the INCLUDEPATH statement from the .pro file, and tried to build, I'm no longer getting the "No such file or directory" error?

I will not even try explaining that. I could if I had contents of both your projects so that I could compare them (especially the .pro files). I just know how both QtCreator and compilers work and I know the error such as you got is not caused by QtCreator.

[creatron]

Hmm...I see. I wasn't aware that the INCLUDEPATH variable effects the #include declarations in that way.
In the documentation, on the "qmake Variable Reference" page, it says the following about the INCLUDEPATH variable:



I interpreted that to mean "it specifies the additional include directories which should be searched when compiling the project".
But now, I see, the emphasis should be on the #include part...

I posted about this same problem on the qtforum.org forums, and was basically just told the same thing.

However, while I was trying that, I discovered the real problem must have been in the .pro.user file I was using before, since when I re-setup the project for the Desktop platform (because I had opened it in my other OS - Ubuntu - installed as a dualboot on the same development computer, and the .pro.user settings were different), and the file was rewritten, I have now gotten past that error. So it seems it must have been an issue with the settings. I noticed that this time when I set it up, I chose the "None" option for the build configuration, instead of choosing "One Debug and One Release for each Qt version" like I had the last time (I believe...), so maybe that had something to do with it, I don't know. Anyway, its fixed now.

Thanks.

I'm on Linux and had the same problem. My solution was to use xterm and set the default Terminal in Qtcreator to xterm (In the menu: Tools, then Options, then Environment, then Terminal, there "/usr/bin/xterm -e")