My CLion project is organized as follows:
main.cpp
foo/bar.h
foo/blah.h
main.cpp has the line #include "foo/bar.h" and the latter is located all right.
But foo/bar.h has the line #include "foo/blah.h" (note the directory name is not omitted, even though both files happen to be in the same directory).
The FAQ suggests that a solution to "CLion fails to find some of my headers. Where does it search for them?" is to add the line
set(INCLUDE_DIRECTORIES .)
to CMakeLists.txt. This vibes as just the right answer since it matches what we'd do on the command line (add the flag -I.), but that doesn't help.
How do I tell CLion that I would like all includes to be relative to a single root?
Related question(s):
Tell CLion to use header include path with prefix
the simple way to do it is this:
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
If you want to dictate include paths for interfaces or installations (e.g. you're writing a library to be imported by other projects) then have a look at the documentation for
target_include_directories(...)
Related
My application need boost lib. There is a boost lib in /usr/lib and boost include in /usr/include/boost, but they aren's what I need. So I compile new boost lib in my home , /home/js/anaconda/.../include/boost and /home/js/anaconda/.../lib.
To use boost in home, I use "-I/home/js/anaconda/.../include/boost" to define the include path, however, It complain error because it find boost in the "/usr/..." path. Then I try use "-I/home/js/anaconda/.../include" (the parent directory) and it works fine!
My question is
1)why it works when I specify the parent directory "/home/.../include" instead of "/home/.../include/boost"? what is the right directory I should specify when I use "-I"?
2)when I use "-I" to specify some directory, will these directory always be the one prior to the /usr directory?
It's a common practice (but not mandatory) to include all the header files of a library into its own directory. This has a few advantages:
When you look for a header file, you don't need to look through the header files of other libraries.
When you read a file with include directives, you can see all the headers that belong to the same library because they start in the same base directory.
When you use -I preprocessor flag to add a directory to the include search path, that directory can either:
Belong to your current project: in the case you have your files organised in directories it may become handy.
Be a part of an external dependency: be it a system library or a dependency installed in a directory of your own. These directories' path end in include following the filesystem hierarchy standard.
In the particular case of boost, the intended use is to -I/path-to-boost-install/include flag and then use an include directive such as #include <boost/optional/optional.hpp> to use one of the libraries in that installation.
The best advice is to read the documentation and look for examples before you start using a library. In the case of boost, you can read the getting started on Unix or getting started on Windows pages:
It's important to note the following:
The path to the boost root directory (often /usr/local/boost_1_75_0) is sometimes referred to as $BOOST_ROOT in
documentation and mailing lists .
To compile anything in Boost, you need a directory containing the boost/ subdirectory in your #include path.
Since all of Boost's header files have the .hpp extension, and live in the boost/ subdirectory of the boost root, your Boost #include
directives will look like:
#include <boost/whatever.hpp>
or
#include "boost/whatever.hpp"
depending on your preference regarding the use of angle bracket includes.
I want to include a header file. I am working in a C++ environment, (C++11, Windows OS, Netbeans 7.3.1 IDE, Cygwin_4.x tool collection). I do not know how I setup the environment/IDE (I did it 6 months ago). I do not understand the fundamentals of the C++ build process or Cygwin related issues either, so I might have to fill in the gaps with some other references/documentation (on what specifically, I'm not sure).
My ultimate objective is to be able to include header files using a syntax that does not require the full file path. I want to write something terse, like:
#include "src\stuff\blah.h" //or even better: #include "blah.h"
The only way I can get my program to compile at all is by using the full file path, like this:
#include "C:\NetBeansProjects\Project1\src\stuff\blah.h"
And, I can only compile once using the full path. If I try to rebuild, it will bomb with the *** multiple target patterns. Stop. error. There are workarounds for this error; those being either 1) deleting the build and dist folders between each rebuild (yikes?), or 2) following this 16 step setup process.
I do not want to follow either of those workarounds because they do not appear to deliver what I want. How can I setup my environment to achieve what I want...of being able to include header files without using full paths?
Thanks to DanielKO for this answer.
In my case, I was able to include with the syntax:
#include "../stuff/blah.h"
I did not have to configure anything under the "Code Assistance" section for the C++ compiler.
All of my code is under "src" as the parent directory in my NetBeans project. It seems that the full path of the file is not required, and the only directory that must be referenced is the lowest level subdirectory (in my case, "stuff").
In NetBeans I've added the path to the list of libraries:
Go to Properties->Select C++->Select 'include libraries'->'Add'
Now: Add the path of the project folder with option "absolute"
Go to Properties->Select C++->Select 'Additional library directories'->'Add'
Now: Add the path of the project folder with option "absolute"
It's very obscure to me why the project doesn't recognize "own" header files.
I'm currently trying to get a program to compile on a system that I don't have control over.
The problem that I'm having is the include directories look like this:
/usr/include:
gmpxx.h gmp.h
/usr/local/include:
gmp.h
In my cpp file, I use
#include <gmpxx.h>
and this finds the correct file in /usr/include, however when gmpxx.h includes gmp.h, it pulls it from /usr/local/include, which breaks the build.
Right now, I see 3 very ugly solutions to the problem
In my cpp file, add #include </usr/include/gmp.h>
Having an absolute include path is pretty ugly and non-portable, and I think that this sort of thing should belong in the Makefile instead of the source.
add the -nostdinc flag to my makefile, and specify the include paths by hand
create local symlinks to the libraries that I really want, and then do local includes (#include "gmp.h")
Is there a better solution that I'm missing?
The search paths for includes are taken in the following order:
The -I command-line option.
The CPLUS_INCLUDE_PATH environment variable.
The standard defaults.
So, you can use either of the first two (whichever seems better/more convenient for your purposes).
Remove gmp.h from /usr/local/include, or find out why you have a software distribution that wants to have gmp.h in /usr/local/include and remove the distribution. I think the problem is caused by you having for some reason two conflicting header file sets for GMP. If you have a standard installation of GMP development files on your system (/usr/include/...) there shouldn't be a reason to have another set of headers in /usr/local/include/.
There's no clean way to fix it otherwise, because you should include gmpxx.h using angle brackets
#include <gmpxx.h>
as you do. Now gmpxx.h includes gmp.h using angle brackets also, and on your system /usr/local/include takes precedence over /usr/include, which kind of makes sense.
So I'd recommend you to figure out why there are two gmp.h's and remove the spurious one. There is something fishy in your header file setup.
You can't easily resuffle /usr/include and /usr/local/include because they are considered system include directories and if you try to use -I on them, GCC will ignore the option.
I'm using VS2010 (downloaded via dreamspark) and although I can open the #include file by right clicking on it and pressing on Open Document, it complains "Error can not open source file "..."" which seems rather absurd. I'm using Qwt with Qt this time around and I'm specifically having the problem for:
#include <qwt_counter.h>
#include <qwt_plot.h>
(And I am using the "<>"); not sure how to make those appear properly in the code above.
Thanks in advance.
As Neil indicated, try using quotes instead of the <> characters around the filename. When using the quotes, MSVC will look in the same directory as the file the #include is in for the specified file, then if it's not found there will look in the directories specified by the include path. When the filename is surrounded by <> characters, the current file's directory isn't looked at - the compiler goes right to the include path.
See http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx for details.
Note that this is an implementation dependent behavior - it might not apply to other compilers.
If that doesn't help, make sure that your include path contains the directory that the file is located in by setting the "Include Directories" property appropriately:
http://msdn.microsoft.com/en-us/library/t9az1d21.aspx
Finally, you might be using a makefile project (I'm not sure how common it is for Qt projects to continue to use qmake when built from VS) , in which case you'll need to perform whatever configuration is necessary in the make file(s) or parameters passed on the command line that invokes the makefiles.
Is the path where these files are located either the same as that of this source file, or included in the "additional include directories" in your project settings?
Project -> properties -> c/c++ section -> additional include directories.
If they are located in a subdirectory of the source file you're editing or of one of the additional include directories (I think) you can also include them with:
#include <path_to_file_1/qwt_counter.h>
#include <path_to_file_2/qwt_plot.h>
[edit]
or of course what neil says
[/edit]
It turned out there was a circular linking happening and I had all my code in a .h file. I split it up and added the corresponding .cpp file, now everything works fine.
I'm trying to get Xcode to import the header file for Irrlicht.
#include <irrlicht.h>
It says "Irrlicht.h. No such file or directory". Yes Irrlicht.h with a capital I, even though the #include is lowercase.
Anyway I added "/lib/irrlicht-1.6/include" in the header search paths for the Xcode project, yet it still doesn't find it.
The only thing I've tried that does work is:
#include "/lib/irrlicht-1.6/include/irrlicht.h"
This is a bit ridiculous though, #include should work, I don't understand why it isn't working.
Update (here are more details on the error):
/lib/PAL/pal_benchmark/palBenchmark/main.h:31:0
/lib/PAL/pal_benchmark/palBenchmark/main.h:31:22: error: irrlicht.h: No such file or directory
I figured this out. Perhaps someone can comment as to why this is the case.
The Header was located in this directory:
/lib/irrlicht-1.6/include/
If I added that path to: "Header Search Paths" Xcode still wouldn't find the path when I built the project.
Solution: Add the header path to: "User Header Search Paths" instead.
It boggles me why I had to do this, as I frequently add my header paths to "Header Search Paths" and then #includes just work. Hopefully this can help someone else who gets this same issue.
Both
#include <irrlicht.h>
#include "irrlicht.h"
should work as long as the "-I" argument to gcc includes the path of the directory enclosing the header file. If irrlicht.h is part of /usr/include the "-I" option is no longer required.
Rather than explicitly adding include paths to your project settings, an easier and more convenient solution for this kind of situation is to just drag the directory containing your .h files (/lib/irrlicht-1.6/include in this case) into the project files pane. This adds the headers to your project of course, and makes it easy to browse them and search for symbols, etc, and it also adds the directory path to gcc compiles, so that you don't have to manage include paths explicitly.
and furthermore, a flat file hierarchy isn't what you want. Dragging files into Xcode flattens your hierarchy. What about for example when you want to have multiple Targets, with a "TargetName/settings.h" file for that target. you'll have many settings.h files that you need to keep unique via its folder name.
I understand that this is an old post, but it does rank quite high on Google, so I thought I would add some information
Under XCode 3.2.6, I had an issue where XCode could not find a header file. It turns out that one of the filepaths included a space in it, and XCode interpreted it improperly.
For example: With a path like "Users/Username/Desktop/Project/Some Headers"
Here was the excerpt from the GCC Commandline: "-I/Users/Username/Desktop/Project/Some" "-I/Headers"
To see your build log provided by XCode, there is a good tutorial here: How do you show Xcode's build log? (Trying to verify if iPhone distribution build zip was created correctly.)