I have a question.
My current project has a header I include at the beginning. I include it like so:
#include <C:/Data/Programming/Project_2018/Files/header.h>
This is proving to be a problem as I can't make it portable to another computer. My question is, can I make some sort of change to the #include in order to force the compiler to seek this header.h in the same folder as the c file that uses it?
#include <.../Files/header.h>
With ... representing the folder where the main.c file is contained?
The final destination for this project is a zip folder which is to be delivered to be used on any computer, so I need this portability...
Any clues?
Yes, you can use relative includes in C. If you're compiling from the directory with main.c in it, #include "header.h" will work for you. Note the double quotes, which tell the compiler to look in the source tree, not the include path.
If your directory structure is something like this:
.../files/
.../files/main.c
.../files/include/header.h
then you'll want to #include "include/header.h". You can also move up the tree, so with
.../files/src/main.c
.../files/include/header.h
you can #include "../include/header.h". The path is unix-y, and in unix land, .. is the parent directory.
This question might also be relevant.
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 trying to check how include directive in c search linux source tree for including kernel header files. For example in my /usr/src/linux-header-5.7.0-kali-common folder which contains subdirectory include/linux I think this is the directory where avaiable kernel header files like socket.h and others are present and they do exists there. so if in c I try to include /usr/src/linux-header-5.7.0-kali-common/include/linux/socket.h header file like
#include <linux/socket.h>
then it works ok. I checked. but when I try to specify some header file in subdirectory of /usr/src/linux-header-5.7.0-kali-common/include/linux/ like file
/usr/src/linux-header-5.7.0-kali-common/include/linux/amba/bus.h which does exists
#include <linux/amba/bus.h> (NOT working)
and tried to compiled it but gcc gave me error like no such file as <linux/amba/bus.h> exists
I like to know that does gcc not searches any place other place than current directory in linux source tree (may be this is a limitation implemented in some makefile which I dont know of or kernel header files are only self contained folder means no sub directories which in that case I may be wrong from the start because /usr/src/linux-header-5.7.0-kali-common/include/linux/ contains many subdirectories
Question
how can I achieve to include header files that are like #include <linux/netfilter/nfnetlink.h> which does exists in /usr/src/linux-header-5.7.0-kali-common/include/linux/netfilter/ folder
I tried to include it by specifying #include <linux/netfilter/nfnetlink.h> but does not work
Question
if someone try to explain when we include like this
#include <linux/socket.h> (WORKING)
which directory or directories may be searched
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.
I'm having an incredibally hard time finding answers to this for Windows. As if the majority of people use Linux...
Anyways, I need a custom CSV parsing library for C. I found one and downloaded the header file. I tried adding #include <csvparser.h> at the top of my c program but of course, it says file not found. I placed the downloaded file in the same directory as the program.
I think i need to be able to specify an absolute path in the include or place the file csvparser.h in the include directory, but I know how to do neither of these things. What is the default include directory in Windows? I use gcc as my compiler. How can i specify an absolute path in the include statement, on windows? i can find no answer to this.
Thanks!
EDIT
Thank you for the quick reply, I seem to have included the file correctly, but now I'mhaving problems using it.
I found the program at https://sourceforge.net/p/cccsvparser/wiki/Home/
I placed it in the source directory and tried using it, bbut when I try the usage example I'm getting an error. This is my code:
#include <stdio.h>
#include <string.h>
#include "csvparser.h"
#define MAXCHAR 10000
int main() {
// int i = 0;
// file, delimiter, first_line_is_header?
CsvParser *csvparser = CsvParser_new("../MagicProg/Files/MagicProg_csv_ikoria.csv", "|", 1);
return 0;
}
When I try executing this, geany gives me the error:
C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Geoff\AppData\Local\Temp\ccsiwJPq.o:hello.c:(.text+0x22): undefined reference to `CsvParser_new'
What am I doing wrong? thanks again
If you're including something that's in your source directory you need to use a different style:
#include "csvparser.h"
The angle-brackets form is exclusively for things found in your include path, not in your source directory. That's reserved for things like OS and compiler headers, as well as system-installed libraries.
I made the huge newb error of not including the src files along with the header file. I blame myself. thanks everyone for help
I know it is possible to specify #include filepaths either relative to the directory the file is located in, as an absolute file path, or relative to any of the directories in the $PATH system variable. Is there a way to instead specify it relative to the user's current directory when the program is compiled? Let's say I have the following file structure:
|--dir_a/
| |--a.c
| |--a.h
|--dir_b/
| |--b.c
| |--b.h
|--makefile
Now let's say I want to #include the file dir_a/a.h from dir_b/b.h. Using the location of dir_b/b.h, this can be written like this:
#include ../dir_a/a.h
However, this approach has a major flaw in my opinion since it hardcodes the locations of files relative to each other, meaning that relocating a file would require updating the file path everywhere that file was included from.
Using absolute file paths would avoid this problem, but would instead hardcode the location of the project within the filesystem, which seems like bad practice.
Finally, using the <> tags to specify the file path isn't feasible either since I can't assume the project will be listed in the $PATH variable.
So what I want to do is to be able to specify the paths relative to where the user compiles from (or even better, from the location of the makefile). In the above example, this would let me use the following statement to #include dir_a/a.h from dir_b/b.h:
#include dir_a/a.h
This I think would be the ideal solution. It would make the #include statements more consistent and easier to follow, as well as avoid the drawbacks I listed above. Is it possible to do this in any way, eg. with a compiler flag or something? I'm using gcc as my compiler.
If you consistently use <> includes, then the -I options in the makefile should be enough. The directory layout shows only one makefile, in the parent directory. That could use
-Idir_a -Idir_b
in the compiler options, and the .c files could just do
#include <a.h>
#include <b.h>
One of the problems with quoted includes is that their behavior with other compilers may differ, as noted in What is the difference between #include <filename> and #include “filename”? (the standard was not explicit enough). Using a gcc extension probably does not improve that situation.
I managed to solve my problem.
The first part of the solution involves specifying the -iquote flag in gcc when compiling. From man gcc:
-iquotedir
Add the directory dir to the head of the list of directories to be searched for header files only for the case of #include "file"; they are not searched for #include <file>, otherwise just like -I.
The second part of the puzzle was how to get the path to the makefile within the makefile itself. This answer worked for me. I'm pasting the solution here for convenience:
ROOT_DIR = $(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))
edit: While this approach works, this answer is more cross-compiler friendly, so I'm personally going to use that.
Yes. Any include file, which is not directly in your include path specified in your project linker settings, should have all subfolders up to it specified, like:
#include "first/second/third/folder/library.h"