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.
Related
I am currently taking a class on C and I am baffled by gcc options a lot of the time, because the videos/documentation on the options are sparse and those that eixst are hard to understand(for idiots/non-technical majors like myself). Please consider the following scenario:
Lets say I have a header file, myHeader.h and main.c which would like to include myHeader.h. Assume they are in the same directory.
In main.c, I could write #include "myHeader.h". However, according to my professor the "" is permitted because gcc will check in the current directory for anything in the "". However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work. I am wondering what gcc commands would work, and why they work in specific. I would love any references(that aren't super nerdy) to better understand this.
So far, I researched on stackoverflow and on google, and it said something about -Idir gcc command, where dir is the directory you would like to add to the header file search path, but I am confused as to why this works or how to actually implement it. Since the "path" to myHeader.h is CStuff/workspace/myHeader.h I attempted to do gcc -I/CStuff/workspace/myHeader.h but this didn't really work out. I really thought it would take that directory and add it to the header file search path, but it just gave me an error.
I am a very confused business major so please take it easy on me! I really would love a dumbed-down explanation or a reference to a source that is more "basic" and has more than 1-2 sentences of explanation(if possible).
However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work.
If you want to add search path directory for system headers, there is -isystem <path>. For ordinary headers — which your header very likely is — there is -I <path>. This supports relative and absolute path formats.
To see which search paths GCC is using, add -v to the options:
> gcc main.c -v ...
...
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
...
There are more special options, see Directory-Options in the GCC documentation, if it comes to search order, for instance.
To see the outcome of including, i.e. the C-preprosessed file, use -save-temps and have a look at the preprocessed file *.i for C, *.ii for C++, *.s for assembly.
To also see built-in and explicit #define's values in preprocessed code, also add -H -g3.
In main.c, I could write #include "myHeader.h". However, according to my professor the "" is permitted because gcc will check in the current directory for anything in the "". However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work.
As a preliminary matter, you are already lost when you conceive the idea that you should want to use that form for the private headers associated with your program. The <header.h> form is conventionally and best reserved for use with system headers. That is, exactly those that do not accompany the code being compiled.
That does not moot the question, however. Sometimes one might want to amend the header search path to help the compiler find headers distributed with the source code and referenced via the "header.h" form, too.
I am wondering what gcc commands would work, and why they work in specific. I would love any references(that aren't super nerdy) to better understand this.
You will not earn friends or respect here by eschewing technical references, nor by casting aspersions on those who do read such references. Technical documents can be hard reading at first, but reading and understanding them is a skill that you will need to cultivate if you want to enjoy success as a programmer.
So far, I researched on stackoverflow and on google, and it said
something about -Idir gcc command, where dir is the directory you
would like to add to the header file search path,
Good start.
but I am confused as
to why this works or how to actually implement it. Since the "path" to
myHeader.h is CStuff/workspace/myHeader.h I attempted to do gcc
-I/CStuff/workspace/myHeader.h but [...] it just gave me an error.
It is important to pay attention to details. You yourself wrote:
where dir is the directory you would like to add to the header file search path
(emphasis added). If /CStuff/workspace/myHeader.h is the header you want gcc to find, then that path is not the path of a directory. The directory is /CStuff/workspace, so -I/CStuff/workspace is a viable option.
Alternatively, for gcc runs in which the working directory is also /CStuff/workspace, you can refer to it by the name . (that is, use -I.). It is a general feature of Unix and Windows paths, not specific to gcc, that the . represents the current working directory.
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.
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"
I have some custom .h files placed under /usr/include, but in a directory (/usr/include/itsmag1c), and I'm trying to include them in my C file. I'm guessing that because I use
#include "filename.h";
for files in the same directory, and I would use angle brackets for including a file like math.h or stdio.h. Am I right in guessing that I would use the angle brackets for including my custom header files? If so, my program wont compile, I get the error that the included files cannot be found. Can someone please point to me how I would include these files, or would it be best to have them in the same directory as my program?
Two choices:
Use #include <itsmagic1c/filename.h>
Use #include <filename.h> as before but add a -I switch.
Boost etc use method 1. (which works well provided you have Boost installed in system locations as you would on a reasonably standard Linux box with reasonable package management).
Method 2. is fine too, but more work on the build system, Makefiles, etc.
Usually, you would put your own headers in the same directory or in a subdirectory. Same-dir includes work with "". For bracket includes, if you use gcc, you can pass additional include directories with
-Irelativedir
or
-I/usr/local/yourpath.
I'm trying to use a non-standard header file (http://ndevilla.free.fr/gnuplot). Its used in lots of codes in various different places on my computer. Currently I have to put the header file and the object file in every folder which its needed with the preprocessor directive:
#include "gnuplot_i.h"
In the file. Is there a way by which I can put the header file in one place so I can reference it like other standard header file. Cheers.
Compile with -I<directory>
E.g.
compile with -I/usr/local/gnuplot/inc.
Also it might be worth your reading up on include paths and the difference between:
#include <include_file.h>
and
#include "include_file.h"
Linking in an object file needs to be done explicitly the same way as a C file, which means (I believe) that you need a full path. However if you archive it into a proper library then you can use -l<library name> and -L<library path> instead. E.g.
gcc -I/usr/local/gnuplot/inc -L/usr/local/gnuplot/lib -lgnuplot -o my_prog my_prog.c
Most compilers have a flag -I that lets you add a directory of your choosing to the search path for include files.