My understanding was always that by doing #include <header.h> it looks in the system include directories, and that #include "header.h" it looks in the local directory. But I was just looking at the python source code and it uses the "header.h" method to define headers in a sibling directory.
So in py3k/Python/ast.c it does #include "Python.h". But Python.h is in py3k/Include/Python.h
Is this something common that I've just never seen, not having worked on any real large C project? How do I tell, at least my IDE, to look in py3k/Include?
Update
I figured out how to tell my IDE to include them, it was just me being stupid and a spelling error. But I'm more interested in why "" works. Is that not the different between "" and <>?
Both #include <header> and #include "header" look in "implementation-defined places", i.e. it depends on the compiler you are using and its settings. For #include <h> it's usually some standard system include directories and whatever you configure the compiler to look in additionally.
The difference between the two versions is that if the search for #include "header" is not supported or fails, it will be reprocessed "as if it read #include <header>" (C99, §6.10.2).
You need to somehow tell your compiler what directories to search in -- for GCC this means using the -I flag. Look it up for your combination of IDE / compiler.
Related
to include /usr/include/test/head1.h file I should write #include "test/head1.h" but how can I just write #include "head1.h" to include this file.
The compiler looks for the usual places like /usr/include for files.
One way to achieve this if you know your compiler already looks at /usr/include for include files anyway, is the following instead:
#include "test/head1.h"
This would be a good approach if you plan to include no more files from /usr/include/test and you know no other include directory has files with similar name to avoid conflict.
Other method would be to give compiler a hint for the directory while compiling:
gcc -I/usr/include/test <other-options> yourcode.c
Have fun writing C!
The answer above mine is correct, but I just wanted to add some advice pertaining to making the #include that you want work if you're using CMake.
If you're using CMake, you can add the path up till your header in CMakeLists.txt, like so:
target_include_directories(<projectname> PUBLIC path/to/headers), and you can add as many paths as you want, separated by spaces.
I am looking at FreeRTOS demo project for an AVR port. The Makefile has paths to the directories where the source files of RTOS are located through an "-I" directive. However, in the main.c module of the project #include does not provide any path like this:
#include "FreeRTOS.h"
So I am not able to understand is that is the "-I" directive required only for linker to find the object files? Does it also mean that once the files are compiled to object code, for GCC they are essentially lying in the same folder if it knows where to look?
I have this confusion because I have seen #include statements like these previously:
#include <avr/io.h>
If GCC already knows the location of io.h why include the "avr" part in front of it?
When we say
#include <foo/bar.h>
the compiler usually looks for a file called bar.h in a directory called foo in one of the places it is configured to look for headers. For example, the standard header search path usually contains `/usr/include', so a file 'bar.h' will be found, if it exists, in '/usr/include/foo'.
If you use the -I switch like this:
-I /usr/include/foo
you could alternatively write
#include <bar.h>
because you've subsumed the directory foo into the compiler's header search path.
However, if foo is some kind of library or module, it's probably more expressive to use a variant of #include that includes the subdirectory foo, rather than manipulating the header search path so that you don't have to.
For the record, the -I switch has no direct effect on linking behaviour.
Incidentally, the variant
#include "foo/bar.h"
conventionally indicated a file in a directory foo in the same directory as the source file. However, modern compilers seem to apply search header paths to these directives as well. I'm not sure whether this is standards-based behaviour, or just compiler writers trying to guess our intentions.
A commit in the C implementation of the Nokogumbo gem is causing the build to fail on Gentoo Linux, however, the modification is minor and shouldn't cause any trouble. Unfortunately, I know next to zilch about C.
Here's the commit:
https://github.com/rubys/nokogumbo/commit/8b4446847dea5c614759684ebcae4c580c47f4ad
It simply replaces the <> with "":
-#include <gumbo.h>
-#include <error.h>
-#include <parser.h>
+#include "gumbo.h"
+#include "error.h"
+#include "parser.h"
According to the GCC docs this shouldn't cause any trouble since it falls back to the previous behaviour:
#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>. You can prepend directories to the list of quote directories with the -iquote option.
Unfortunately, while it compiles just fine with <>, the build fails with "":
compiling nokogumbo.c
nokogumbo.c:24:20: fatal error: parser.h: No such file or directory
#include "parser.h"
I'm wondering to what degree the way <> and "" behaves depends on the toolchain, environment and other settings.
Thanks a lot for your hints!
Re-installing "gumbo" on the Gentoo box has fixed the problem. Apparently, a local installation mess has produced this weird behaviour.
I checked your git repository and I noticed that you compile code with --std=c99. I think this may cause the problem, Because I found this in C99 draft:
The named source file is searched for in an implementation-defined
manner .If this search is not supported, or if the search fails, the
directive is reprocessed as if it read
#include <header>
So it means process is first implementation defined, and if not supported it uses #include<> mode. But this means if it defines that #include"" searches current directory, it will stop searching like #include<>.
There are two ways to include a file in C :
#include <headerpath/header.h>
or
#include "headerpath/header.h"
The first one will look for the file by using a directory known by the compiler, so we can include standard files without knowing where they are.
The second way will look for the file by using only the path between quotes. (if the search fails, the compiler tries the first way instead).
We have the possibility to add one or more directories into the directories's list that the compiler know (first way). For example with gcc we have the -I option.
So at the end, these two following codes are equivalent (path_to_header is a directory) :
1)
#include "path_to_header/header.h"
int main(void)
{
return (0);
} // Compiling with : gcc main.c
2)
#include <header.h>
int main(void)
{
return (0);
} // Compiling with : gcc main.c -I path_to_header
So my questions are :
With my own header files for example, should I use the 1) or the 2) ? Why ? Maybe it's just a personal choice ? Are there different situations to know ?
Thank's for reading :)
Edit :
I'm not looking for the difference between the two ways (I think I understood them as I explained, thanks to this post), I wanted to know if there are some special situations to know about, maybe for group work or using different compilers for the same program ... Maybe I do not know how to formulate my thoughts (or it's a silly question without real answer), I have to try to know :).
For headers of the standard libraries (which probably are precompiled) use:
#include <stdio.h>
For headers of your project use:
#include "project/header.h"
Use the option -I on the command line for additional libraries.
According to the C standard the only standard difference between them is that #include <...> includes a header while #include "..." includes a source file (and falls back to the <...> behavior if no source file is found). All other differences are implementation-defined.
The distinction is important because, for example, a standard header like stdlib.h might not actually be a file, and is instead injected by the compiler at compile time.
For your own code, since you won't have such header magic, and should know exactly which source files you want included from your own work and which you want the compiler to handle (system libraries and such) you should only use <...> for includes that are not part of your project's file structure.
If your own header files are in a defined path, like the same folder with your files that use your headers you must use this way "header.h".
You must use < header.h > when the header is a system header that is not with your sources where you are including it.
I'm looking at the legacy C project which relies on GNU Autotools. The existing M4 script (incorrectly) checks for FreeType headers like this:
AC_CHECK_HEADERS(freetype.h)
which is not the way FreeType should be included. The right way is:
#include <ft2build.h>
#include FT_FREETYPE_H
How do I require that all headers are included in the test program, not either of them?
To check for multiple headers depending on each other, you can use AC_COMPILE_IFELSE
Also if you google for "freetype m4" you will find several macros how to detect freetype.