Given the file tree:
DLL1
└───source
├───File1.h
└───SameHeader.h
DLL2
└───source
├───File2.h
└───SameHeader.h
File1 includes SameHeader.h, which is fine.
File2 includes File1 which won't compile, because the #include "SameHeader.h" now points to the DLL2/source/SameHeader.h. Is there a way to ensure File1 uses the file which in the same dll?
Sure - you can put the file SameHeader.h in a separate folder (not the same as the source files) and then specify that folder in your list of include paths to search (in the project options, or in the compiler command switches).
You will, of course, need to delete the file SameHeader.h from each of the source project directories, or that will be used in preference to the one in the separate folder.
So, using your "file tree" diagram, I would suggest this:
DLL1
└───source
├───File1.h
DLL2
└───source
├───File2.h
Include
└───SameHeader.h
You could then add ../Include to your compiler's include file search path. How to do this depends on your compiler and/or environment, but it will be something along the lines of a /I"..\_Include" switch in MSVC or (probably) -I"../_Include" with clang. This is what I do in multi-project solutions, for all header files that will be used by more than one project.
However, if you actually need two (different) SameHeader.h files, then you should perhaps specify the full path name (or, at least, a qualified path) in the #include "SameHeader.h" line in File1 - something like: #include "../../DLL1/source/SameHeader.h" (depending on the exact layout of your files & folders).
Related
I am trying to include a few libraries in code blocks, however when I add the path of the .h files to the search directory (example C:\Qt\5.1.1\mingw48_32\include\QtNetwork), it only seems to identify the ones in the main file and I think that is due to the fact that in the main file they are included as such (for example) #include "qtcpsocket.h", whereas in the .h file they are included as (for example) #include <QtNetwork/qabstractsocket.h>.
Apart from the fact that one includes the folder in which it is located, what is the major difference? Why it may not work? and what do it need to do to change it?
one more thing I'm sure the files are in the folder.
Here are a few code snippets if this helps
location of file
error
If your source code contains, e.g.
#include <QtNetwork/qabstractsocket.h>
then you are requesting the preprocessor to find and include a file called
QtNetwork/qabstractsocket.h
(or, QtNetwork\qabstractsocket.h, if you're on Windows, as you are)
in one of its search directories.
And if you have specified compiler search directories:
C:\Qt\5.5.1\mingw48_32\include\QtNetwork
C:\Qt\5.5.1\mingw48_32\include\QtCore
then the preprocessor will search the first directory for:
C:\Qt\5.5.1\mingw48_32\include\QtNetwork\QtNetwork\qabstractsocket.h
which does not exist. And it will search the second directory for:
C:\Qt\5.5.1\mingw48_32\include\QtCore\QtNetwork\qabstractsocket.h
which does not exist either.
The usual way would be to specify the compiler search directory:
C:\Qt\5.5.1\mingw48_32\include
and in your code write your #include <...> directives like:
#include <QtNetwork/...>
#include <QtCore/...>
In a "working directory" I have a lot of *.cpp and *.h files that #include each other and files from subdirectories.
For example:
#include "first.h"
#include "second.h"
#include "dir1/third.h"
#include "dir2/fourth.h"
In my own directory (that is different from the "working" directory) I would like to create a new *.cpp and *.h file that includes one of the files from the "working" directory. For example:
#include "/root/workingdirectory/first.h"
However, it does not work. Because "first.h" might include "second.h" and "second.h" is not located in my directory. Is there a way to tell the compiler that it needs to search included files not in the current but in the working directory: /root/workingdirectory/?
To make it even more complex, dir1 and dir2 are not located in my working directory. They are located in /root/workingdirectory2/. So, my second question is if it is possible to resolve this problem by letting compiler know that subdirectories are located somewhere else?
I also need to add, that I do not use any environment for development and compile from the command line (using g++).
As you've already been told, it's useful to read the manual - specifically this chapter - and even more specifically right here.
Specifically, you want
g++ -I/root/workingdirectory -I/root/workingdirectory2
Note also the documentation on #include directive syntax, described here as:
2.1 Include Syntax
Both user and system header files are included using the preprocessing
directive #include. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I
option (see Invocation).
#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. The argument of
#include, whether delimited with quote marks or angle brackets,
behaves like a string constant in that comments are not recognized,
and macro names are not expanded. Thus,#include <x/*y> specifies
inclusion of a system header file named x/*y.
However, if backslashes occur within file, they are considered
ordinary text characters, not escape characters. None of the character
escape sequences appropriate to string constants in C are processed.
Thus, #include "x\n\\y" specifies a filename containing three
backslashes. (Some systems interpret \ as a pathname separator. All
of these also interpret / the same way. It is most portable to use
only /.)
It is an error if there is anything (other than comments) on the line
after the file name.
So for example
#include "first.h"
will start looking in the same directory as the .cpp file containing this directive (or take a relative path as relative to this directory).
If you want to use the include path (specified by -I) you should use
#include <dir1/third.h>
Usual practice is to use the #include "local.h" form for headers inside a library/package/module (however you've chosen to organize that), and the #include <external.h> form for headers from external/3rd-party or system libraries.
Read The Fine Manual
It's there for everyone to read. You even have a choice of what to use (I'd go with the first):
-Idir
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
-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.
For gcc it is the -I option for header includes. For the .cpp files you just need those to appear as an argument to the gcc command.
Every C/C++ compiler (g++, gcc, MinGW, clang, e.t.c.) has a folder called "include" in it's root path where it automatically looks for header files. If you use MinGW, it would be in, for example: "C:\MinGW\include". Just save your header to the include folder like this: C:\MinGW\include\header1.h or C:\MinGW\include\LibGUI\Window.h
I tried to shorten down my question (the Old question can still be found below)
My current directory structure looks like this
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
I can include the .h files from ..\utility\include with #include <file.h> to proj1, if I add this directory as include path to my IDE (in proj1). Is there an aequivalent solution for the ..\utility\src files? I am using LPCXpresso IDE on Windows 7. I suppose there is the same solution on any IDE, so I just want to know how this whatever path (where .c files will be searched, if not found in the .\src directory) is generally called to find it in my project settings.
I try to avoid using libraries (.lib, .dll)
I don't want to copy the .c files in each project (proj1, proj2, ..., projn)
I want to be able to simply edit the .c and .h files and if recompiling proj1 and so on the changes will be applied, as they will for all other projects
Generating an own makefile may be a solution (but shouldn't there be an Option to add a source-file-path in IDEs?)
#include <..\utility\src> is a non-desired solution as changes to the directory will fource to add this line in each single file, where changing a path in the Options are only some clicks.
Thanks in advance and thanks for the answers up to now
Old Version of my question:
Motivation: Imagine, you write a program in C/C++ in some IDE and have .c and .h source code files as usual. In addition you have a helper.c and helper.h file, were you defined some useful, not project related functions (which can be used in several projects). You want to include these files, but don't want to have them were you store your project related source code.
As far as I know .h files can be stored in a separate folder, which is pointed to by the includepath. This path can be set in every IDE. Further it changes the
#include "helper.h"
statement to
#include <helper.h>
If I put the .c files in the same folder and not include them separately, the compiler will not find them. If I include them as well with
#include <helper.c>
a multiple inclusion will lead to multiple function deklaration and therefore to a compiler-error. Only solution may be an
#ifndef helper_c_
//content of helper.c file
#endif
, which is kind of impractical and will always need inclusion of the .h and the .c file. But i only need to have them stored once, with no copies and if i need to change something, it will change in all projects, as they are all pointing to that folder
I also now about library files, where you have an .lib and a .dll file, where the .lib file needs to be pointed at by the library-path and the .dll file needs to be in the same folder as the .exe file afterwards. But that is not what i want.
My Question: Is there a possibility to store the .h and .c file (in my current case there are 10 file-pairs) in a separate folder and point at them via an include path or so? I tried googling around, but I think I am not quite sure what i shall look for.
Thanks for help
EDIT: I forgot to mention: I use Windows 7, and my current IDE is the LPCXpresso-IDE
OK, suppose you have this directory structure:
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
And also assume, that the current directory for compilation is in the proj1/src directory. I see at least three solutions to your question:
if you really want to #include the source files, which I do not recommend doing, just use a relative path to the files i.e.
#include "..\..\utility\src\file1.c"
Now in addition to the issues with including source files, this tends to be very fragile in that if you change the directory structure (or change a name of a directory) everything breaks. You would need to go back into your source and fix every line of code.
As iharob suggested, use a make file to handle this. In this case, you would have a compile line that looked like this (assuming you are using Microsoft's tool change);
cl /I..\..\utility\include ..\..\utility\src\file1.c /o util_file1.o
This causes the result of the compilation to be dropped in the current working directory and the linker will be able to find all the object files and combine them together into one executable. We still are dealing with relative paths here, but all the changes would be in a single file, and by using make variables the changes would be on a single line or two.
If the functions in the utility directory are going to be used in multiple projects, my personal favorite solution is to make a utility project that produces a dynamic library (a dll under windows) and link subsequent projects with that library. You still have to deal with locating where the include files are going to be (maybe a directory at the top level of where all your project folders are?), but to me a library seems cleaner. It also has the added advantage that if you want to modify the code in the utility project, just recompile the library and the rest of you project will 'see' the modifications with out recompilation of them (assuming you do not modify the interface of the library).
Hope this helps,
T
Yes of course there is, depending on what compiler you are using there will be a switch to tell the compiler where to search for headers, for gcc and some others AFAIK, it's -I, so for example suppose that your headers are in the myproject/headers directory, the compiler should be invoked like this
gcc -I myproject/header ${OTHER_OPTIONS} ${SOURCE_OR_OBJECT_FILES} -o ${OUTPUT_FILE}
The usual way to build a project with the .c files in different directories is to use a Makefile and a program that can parse the Makefile and invoke the neecessary commands to build the project.
A word of warning: it is generally not a good idea to #include source (.c) files. The source files are meant for compilation, not inclusion -- including them may result in strange errors (most prominently, apparent re-definitions of a function).
Here is what I would do (for each project that needs the helper code):
Add your utility .c files to the project. Look for Add existing file... or a similar IDE feature; this ensures that your utility source files, i.e. helper.c, get compiled along with your project.
As for the .h file, include it with #include <helper.h>, enabling you to use your utility declarations.
Finally, find a compiler option called Include paths, a.k.a. -I, and set it to the folder that contains helper.h. This is usually found in Project options/settings.
After looking around through all the settings and options I found the following satisfying solution: creating a Link to a source file folder
This answer applies to the LPCXpresso IDE
imagine the folder structure shown in my question
inside the LPCXpresso IDE -> rightclick on the project -> properties
navigate to C/C++ General>Paths and Symbols>Source Loacation
click "Link Folder..."
in the opened dialog tag the checkbox Link to folder in the file system
click Browse... or enter C:\users\documents\projects\utility\src
click OK
click Apply
recompile and be happy :)
I'm using a library with an include structure where the .h files are all in a single directory. These .h files contains a single line, a #include directive which points to the 'real' header file in specific source folder locations. The #include path in these files is relative.
So, here's an example. The directory structure is:
/project
/sources
<my .cpp files>
<my .cpp files>
...
/include
/component
foo1.h
foo2.h
/platformA/something/foo1.h
/platformB/somethingelse/foo2.h
/include/component/foo1.h contains a single line of code:
#include "../platformA/something/foo1.h"
/include/component/foo2.h contains the single line of code #include "../platformB/somethingelse/foo2.h"
In my sources, I simply have:
#include "component/foo1.h"
The header search path for my project points to /include
Now, Xcode 4 is able to find component/foo1.h in /include, but it's unable to follow the relative include path within those headers and find the 'real' foo1.h in the `/platformA/something' directory, and so on.
I suspect it's because the include paths in the top-level foo1.h file is relative to its location, but Xcode might be treating it as relative to some other location (project root or something)? FWIW, Visual Studio has no problems with an identical configuration.
What can I do to remedy this?
From your directory structure it seems that the directories platformA and platformB are placed outside the include folder. There are two possible solutions to this:
Solution A
Move these
to include folder.
Solution B
Add project/platformA and
project/platformB to the
directories where include files
should be looked for in project
settings.
Don't use relative paths. Seriously, it's implementation-defined behavior how they work, so different compilers/environments/platforms will behave differently, and in your case, Xcode is almost certainly invoking GCC or clang in some sort of "build" directory, which may or may not be a sibling to your sources directory.
It's not worth the headache.
Put platformA and platformB in include, or add another directory (say, platform-include) put them in there, and add that directory to your include path.
I'm studying C++ right now, coming from a background in Python, and I'm having some trouble understanding how C++ handles multiple source files. In Python, the import statement first checks the current working directory for the module you're trying to import and then it checks the directories in sys.path. In C++, where would I place a custom made .h file? Where would the compiler even look?
For example, I've got a program, foo.exe compiled from a single source file, foo.cpp, both in the same directory. I decide that I want to organize things a little better, so I create a new .h file, bar.h and dump stuff in there. Would I just need to #include to get to the stuff I put there? What if I want to use bar.h with another program (in a completely different directory)?
There are two include variants:
#include "path-spec"
#include <path-spec>
Quote notation:
This form instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of any files that include (#include) that file.
The bracket notation looks for header files in certain defined locations.
With gcc you can get some information about these pathes via:
$ echo | gcc -v -x c++ -E -
Compilers accept
-I or /I
options to add additional pathes.
It (generally) looks in the include path if you use #include <foo>, else it uses relative paths if you use #include "../../foo/bar.h".
You set the include path with -I or /I on most compilers. Consult its manual for details.
Don't define any objects in headers though -- you will have multiple definition errors at link time if you do (and include the header in multiple source files).
It works in a similar way. The #include only is used by the compiler. In execution time the file bar.h doesn't gets used. But in compile time it is.
In compile time, the file could be in two places:
1.- The current directory (as in python)
2.- The directories configured in your include path. Where to configure that directories depends of the compiler you are using. Most of them let you define the include directories in the compile command line. And most IDEs let you configure it in some Options menu.
Hope it helps.
If your header files are in the same dir, you can include them like:
#include "bar.h"
If you want to include this header from another dir:
#include "../foobar/bar.h"
Basically quotations mean to search from current directory and brackets like in #include <abc.h> mean to search in standard header file directories. You can add custom directories to the standard search path by adding a -I /path/to/your/custom/headers in the compile command.
#include with angle brackets looks in the system include directories. Like this:
#include <iostream>
With double quotes it looks in the current directory and other directories given to the compiler to search.
#include "foo.h"
g++ -I../include foo.cpp
the thing you are missing in the python model is the linker.
in python you import code and its interpreted right there and then. in c/c++ you compile each source file into an object file. You then tell the linker to collect a bunch of object files into an executable
Typically the includes in c/c++ source files only contain descriptions of whast in the other C files (the names of functions, etc) not the function contents. This is enough for the compiler to compile a given file. Then the linker will combine your object files with libraries of 'well known' functions and make an executable