Say you have 100s of source files (.c or .cpp) files, and you want to include some definitions, function/variable declarations in each of them. Normally in C/C++, you use header files for that purpose. But in this case you need to put #include "header.h" in each source file.
Now my question is, is there a way to include one header for all the files without putting #include "header.h" in each of the file, because it will be very tiresome to write #include "header.h" for 100s of source files.
You can use the -include flag for clang or GCC. From the man page:
-include file
Process file as if "#include "file"" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the "#include "..."" search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
Example:
clang -include header.h -c file1.c
clang -include header.h -c file2.c
clang -include header.h -c file3.c
clang -o app file1.o file2.o file3.o
MSVC has the /FI flag, which is similar.
You could solve this problem using a unix pipe
find ./ -name "*.c" -or -name "*.cpp" | xargs -n 1 sed -i '1 i #include <my_header.h>'
You can't do that, although you could write a script for you to do it. A script that takes each files, and writes #include "header.h" at top. Edit: -include in gcc does this.
However, what you need is achievable in a different way through the compiler options. In gcc, with -D.
Let's say, you want the define DEBUG_LEVEL to 2 in all your source files. You can simply do this by invoking gcc like this:
gcc -DDEBUG_LEVEL=2
Note that in this case, you would need to rebuild all your project (which would have been done anyway if you had changed this definition in 1 header file to which ALL the source files depend on)
Header files are not definitions - they are declarations.
You put as few in as possible - saves the compiler work and also inter-dependencies.
You can even reduce the number further by using forward declarations in those header files.
If you are clever you can get you IDE to help you out with filling in the gaps instead of hurting your fingers.
Related
We link in a library(TAO) which is composed of many header files.
Every time I run the pre-processor command on a cpp file( g++ -MM $< $# ), these library files are automatically included in every .d file generated.
These are obviously not system files and almost never change as far as we're concerned, so I would like to eliminate them from my .d files.
Short of filtering out these header files using sed, is there any built in way to accomplish this?
You may instruct gcc to consider some path as system headers with -isystem; and g++ -MM ignore system-headers.
I am in the App folder of my project. I run the following command to compile character.cpp
g++ -Wall -std=c++11 -I../App -c Character/character.cpp -o Obj/character.o
which is in App/Character directory. character.cpp has the following include
#include "Inventory/inventory.hpp"
where the folder of inventory.cpp is App/Inventory.
I thought because I am running the g++ command from App, the default include path would start from App and therefore I wouldn't need to have the -I../App part of the command. To me this seems to be saying "move one level higher than App then move into App and include from there" which seems redundant but without that line it doesn't work.
Can anyone explain why?
EDIT
Looking at it again and some more documentation, I believe that if no -I path is specified, g++ will look in its default directories and then all other includes (like the one I have causing problems) are relative to the file that includes them. So I have to add the -I part to say "look in the App directory too" and since it doesn't like just -I, I have to use ../App because that is equivalent to not moving at all. Can anyone confirm if this is at all accurate?
You can use -I. for searching headers from the current directory, instead of -I../App.
This include preprocessor directive
#include "Inventory/inventory.hpp"
forces gcc (g++ or cpp) to search the header not from the current path (App/), but from directory of your source file (App/Character):
/root/App# strace -f g++ -c -H ./Character/character.cpp 2>&1 |grep Inven
[pid 31316] read(3, "#include \"Inventory/inventory.hp"..., 35) = 35
[pid 31316] stat64("./Character/Inventory/inventory.hpp.gch", 0xbfffe6a4) = -1 ENOENT (No such file or directory)
[pid 31316] open("./Character/Inventory/inventory.hpp", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
..then try system directories
This is documented here: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
GCC looks for headers requested with #include "file" first in the directory containing the current file
This behavior can be not fixed in the Language standard (ISO C), and is implementation-defined (as commented by Richard Corden and answered by piCookie in What is the difference between #include <filename> and #include "filename"?):
specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner.
But this is the way the C compiler should work under Unix, according to Posix, aka The Open Group Base Specifications Issue 7:
Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified.
It is useful when your current directory is far from the source directory (this is the recommended way in autotools/autoconf: do mkdir build_dir5;cd build_dir5; /path/to/original/source_dir/configure --options; then make - this will not change source dir and will not generate lot of file in it; you can do several build with single copy of source).
When you start g++ from the App directory with -I. (or with -I../App or -I/full_path/to/App), gcc (g++) will find the Inventory. I added warning to the header to see when it will be included; and -H option of gcc/g++ prints all included headers with pathes:
/root/App# cat Inventory/inventory.hpp
#warning "Inventory/inventory.h included"
/root/App# cat Character/character.cpp
#include "Inventory/inventory.hpp"
/root/App# g++ -I. ./Character/character.cpp -H -c
. ./Inventory/inventory.hpp
In file included from ./Character/character.cpp:1:
./Inventory/inventory.hpp:1:2: warning: #warning "Inventory/inventory.h included"
For getting a preprocessed output, following command is used:
g++ -E a.cpp > temp.cpp
If a.cpp has #include files not in the same folder, then we use:
g++ -I <directory> -E a.cpp > temp.cpp
Now, there are several .cpp file for which I want a preprocessed output.
Also a huge #include dependency for every .cpp file and the header file is spread in several different subdirectories; so following option is very cumbersome:
g++ -I <dir1> -I <dir2> -I <dir3> ... -E a.cpp > temp.cpp
Is there any simpler way (preferably without the use of Makefile) ?
(Assume that dir1, dir2, ... are under a single directory)
You need the same set of -I for preprocessing and for compiling.
When you actually compile the code, you surely use some set of -I parameters (probably generated by a make file).
So just use the same (or compile, and copy&paste the -I parameters).
The only alternative I see is restructuring your header directories to be in a common directory (with sub-directories, using #include <subdir/header.h>).
But this is much more work (though it may be worth the effort).
One way can be that you give the TOP directory in which all the subdirectory resides. This way you wont have to give many -I. But this will slowdown it.
I have a directory maths which is a library that is comprised solely of header files.
I am trying to compile my program by running the following command in my home directory:
g++ -I ../maths prog1.cpp prog2.cpp test.cpp -o et -lboost_date_time -lgsl -lgslcblas
but I get the following compilation error:
prog1.cpp:4:23: fatal error: maths/Dense: No such file or directory
compilation terminated.
prog2.cpp:6:23: fatal error: maths/Dense: No such file or directory
compilation terminated.
maths is located in the same directory(i.e. my home directory) as the .cpp files and I am running the compilation line from my home as well.
prog1.cpp and prog2.cpp have the following headers
#include<maths/Dense> on lines 4 and 6 respectively, hence I am getting the error.
how do I fix it.
You can either change your include path to -I.. or your includes to #include <Dense>
Wait, if maths is in the same directory as your source files and that is your current directory, you can either change your include path to -I. or your includes to #include "Dense"
maths is located in the same directory(i.e. my home directory) as the .cpp files
Your include path is given as -I ../maths. You need -I ./maths – or simpler, -I maths since maths is a subdirectory of the current directory, not of the parent directory. Right?
Then in your C++ file, use #include <Dense>. If you want to use #include <maths/Dense> you need to adapt the include path. However, using -I. may lead to massive problems1, I strongly advise against this.
Instead, it’s common practice to have an include subdirectory that is included. So your folder structure should preferably look as follows:
./
+ include/
| + maths/
| + Dense
|
+ your_file.cpp
Then use -I include, and in your C++ file, #include <maths/Dense>.
1) Consider what happens if you’ve got a file ./map.cpp from which you generate an executable called ./map. As soon as you use #include <map> anywhere in your code, this will try to include ./map instead of the map standard header.
I'm trying to compile a third-party library, but g++ is complaining about the following line:
typedef boost::shared_ptr<MessageConsumer> MessageConsumerPtr;
The strange thing is, there is no #include directive in the file - and it is clearly supposed to be this way; there are about 60 files with the same (or very similar) issues. Clearly if there was an #include directive referencing the relevant boost header this would compile cleanly.
My question is: how can I get g++ to somehow automagically find the relevant symbol (in all instances of this issue, it is a namespace that can't be found - usually std:: or boost::) by either automatically processing the relevant header (or some other mechanism).
Thanks.
Edit
My current g++ call looks like:
g++ -fPIC -O3 -DUSING_PCH -D_REENTRANT -I/usr/include/boost -I./ -c MessageInterpreter.cpp -o MessageInterpreter.o
You can use the -include command line option:
g++ -include boost/shared_ptr.hpp ...
From the man page:
-include file
Process file as if "#include "file"" appeared as the first line of
the primary source file. However, the first directory searched for
file is the preprocessor's working directory instead of the
directory containing the main source file. If not found there, it
is searched for in the remainder of the "#include "..."" search
chain as normal.
Create your own wrapper .h file that includes the boost .h and then the broken .h .
Or (very fragile) ensure that you precede every use of the broken .h with boost .h .
Perhaps the third-party library is designed in such a way that you should always include a certain "main" header file in order to get the dependencies right.
Otherwise, you can add #include <boost/shared_ptr.hpp> before including the third-party header file that is giving the error message.