preprocessor #include
-
I am an innocent bystander of a discussion about how #include directive is handled in IDE. The IDE in question uses proprietary file "main" name extension (still a text file) and processes #include and #include "local_header.h" in that file just fine. However, when the local_header.h file has another #include in it the compiler "does not see that". That is basically what people who "knows / developed" the IDE are saying. Including another local file in first local file such as #include "local_header_1.h" is "seen / processed " by IDE. I was under the impression that #include tells the OS to find the file "anywhere" and #include "file.h" tells the OS to search only current / parent directory. So why is IDE (gcc) getting into the act?
Vaclav_Sal wrote:
However, when the local_header.h file has <b>another #include <header_1.h></b> in it the compiler "does not see that".
That is wrong. The compiler (or more precise: the preprocessor part) will process such includes. However, an IDE may do other things with your files before they are passed to the compiler. But GCC is the Gnu Compiler Collection (a collection of command line tools) and not an IDE.
-
I am an innocent bystander of a discussion about how #include directive is handled in IDE. The IDE in question uses proprietary file "main" name extension (still a text file) and processes #include and #include "local_header.h" in that file just fine. However, when the local_header.h file has another #include in it the compiler "does not see that". That is basically what people who "knows / developed" the IDE are saying. Including another local file in first local file such as #include "local_header_1.h" is "seen / processed " by IDE. I was under the impression that #include tells the OS to find the file "anywhere" and #include "file.h" tells the OS to search only current / parent directory. So why is IDE (gcc) getting into the act?
A compiler is not an IDE. An IDE is a front-end to a compiler and it should follow the same rules as the compiler (and pre-processor in this case). If the IDE does not, then it is broken and must be fixed.
-
#include
This variant is used for system header files. It searches for a file named file in a standard list of system directories.
#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html[^]
FTFY
Chris Losinger wrote:
This variant is used for system or library header files.
-
A compiler is not an IDE. An IDE is a front-end to a compiler and it should follow the same rules as the compiler (and pre-processor in this case). If the IDE does not, then it is broken and must be fixed.
Thanks for confirming my suspicions. Obviously I got the compiler mixed up , so here is the way I view the whole mess. To get from idea to running code I see these basic blocks Operating system - with environment configuration Development application (IDE ) Development tools Text editor Main file .*ino "System " includes - example IDE "libraries" - example Local includes - example "MyClass.h" Compiler / linker (preprocessor) Executable code I think I need to take a look how the compiler handles / finds the path to each include. I can see if local includes are in SAME directory as the x.ino file it works fine. But the "system" or "library" includes path are different and that why if fails. But I want to write code and not troubleshoot the IDE. Maybe I should use a different IDE. Cheers Vaclav
-
Thanks for confirming my suspicions. Obviously I got the compiler mixed up , so here is the way I view the whole mess. To get from idea to running code I see these basic blocks Operating system - with environment configuration Development application (IDE ) Development tools Text editor Main file .*ino "System " includes - example IDE "libraries" - example Local includes - example "MyClass.h" Compiler / linker (preprocessor) Executable code I think I need to take a look how the compiler handles / finds the path to each include. I can see if local includes are in SAME directory as the x.ino file it works fine. But the "system" or "library" includes path are different and that why if fails. But I want to write code and not troubleshoot the IDE. Maybe I should use a different IDE. Cheers Vaclav
Vaclav_Sal wrote:
But I want to write code and not troubleshoot the IDE.
There is nothing to troubleshoot. Whether you use the IDE or not, the issues are the same. The compiler needs to know the paths of any directories which contain header files that you wish to include in your compilations. The linker needs to know the paths of any directories which contain libraries that are referenced by your project. When you install Visual Studio it sets a default set of both, which gives the paths to all the default library components. If you create a project that uses other headers and libraries then you need to add those paths, and the library names, using the Project Properties link in Solution Explorer. If you want to do it without using the IDE then it is much more hard work and you would probably need to set up some complex batch files, or learn how to use Make: something that is not for the fainthearted.
-
Thanks for confirming my suspicions. Obviously I got the compiler mixed up , so here is the way I view the whole mess. To get from idea to running code I see these basic blocks Operating system - with environment configuration Development application (IDE ) Development tools Text editor Main file .*ino "System " includes - example IDE "libraries" - example Local includes - example "MyClass.h" Compiler / linker (preprocessor) Executable code I think I need to take a look how the compiler handles / finds the path to each include. I can see if local includes are in SAME directory as the x.ino file it works fine. But the "system" or "library" includes path are different and that why if fails. But I want to write code and not troubleshoot the IDE. Maybe I should use a different IDE. Cheers Vaclav
Vaclav_Sal wrote:
Main file .*ino
Are you working with Arduino?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Vaclav_Sal wrote:
Main file .*ino
Are you working with Arduino?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Vaclav_Sal wrote:
But I want to write code and not troubleshoot the IDE.
There is nothing to troubleshoot. Whether you use the IDE or not, the issues are the same. The compiler needs to know the paths of any directories which contain header files that you wish to include in your compilations. The linker needs to know the paths of any directories which contain libraries that are referenced by your project. When you install Visual Studio it sets a default set of both, which gives the paths to all the default library components. If you create a project that uses other headers and libraries then you need to add those paths, and the library names, using the Project Properties link in Solution Explorer. If you want to do it without using the IDE then it is much more hard work and you would probably need to set up some complex batch files, or learn how to use Make: something that is not for the fainthearted.
Richard, I feel you missed my question. Just FYI, the IDE I am using is pretty tight lipped about "an additional path" I experienced using my VC++. It just was not build to expand... I posted my question here for reasons which I do not wish to discuss. Thanks anyway.
-
Yes, I'll take wild guess what you are going to say...on better not... Anything after ONE file is a challenge.
Vaclav_Sal wrote:
I'll take wild guess what you are going to say...on better not...Anything after ONE file is a challenge.
Negative. I was just trying to narrow down the problem a bit. The Arduino IDE uses the avr-gcc compiler. That compiler's preprocessor, like others, has a list of directories it will search to resolve
#includedirectives. This is usually the-Icommand-line switch."One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Richard, I feel you missed my question. Just FYI, the IDE I am using is pretty tight lipped about "an additional path" I experienced using my VC++. It just was not build to expand... I posted my question here for reasons which I do not wish to discuss. Thanks anyway.