I'm developing a library that is to be used (after compiled and installed) by another developer. All my includes are like this:
#include "../exception/CException.h"
All goes well but when I install the library and use it in another program with #include <> that include a file that have #include "../exception/CException.h" the last file is not found. Why?
Any help to improve include usage?
The problem with a relative path is that we don't know for sure what it is relative to. Different compilers have different ways of doing this.
You should rather use
#include "yourlib/exception/CException.h"
similar to Boost.
If you install this as a subdirectory yourlib in /usr/local the compiler should be able to find that.
You'll need to distribute ../exception/CException.h with your library. If it's really part of your library putting it in a subdirectory rather than a sibling would be preferable.
Related
I'm trying to make a cross-platforms crypto library in C++ at https://github.com/haithngn/cryptor something like https://github.com/MailCore/mailcore2
The Structure is:
Can I make any header files can be include in the statements like this:
#include <Cryptor/MD5Encryptor.h>
I can include these header directly from absolutely file path
../core/CryptorCore.h
But these format will make the source code cannot build succeed in an XCode Project.
I tried to simulate the MailCore2 but that's very difficult.
Hope you can suggest me any solution or do a favor PR on my Repository.
Thanks,
You need to have a proper hierarchy. First, no, you can't have
#include <Cryptor/MD5Encryptor.h>
with your current setup, not while building the library, and not without flattening the hierarchy when installing your files (which CMake can do).
What you can do is:
#include <Cryptor/core/abstract/MD5Encryptor.h>
if you add your project inside a Cryptor folder instead of being at the root of your project.
I would advise you to create a Cryptor.cmake file that would allow people to pick up your library once installed, so that they don't have to know where the library includes are or what the libraries name is.
It should not be necessary to point to every single header file. Just add all directories containing these header files with include_directories(PATH_TO_HEADERS).
For the include of the header file src/core/CryptorCore.h with
#include "CryptorCore.h"
you have to point to
include_directories(${PROJECT_DIR}/core/)
I use a code with different libraries, which use names like defines.h. This does not only cause conflicts for identical filenames, but also creates confusion. From which library is the defines.h include?
Including as #include <library/defines.h> would be a clean solution, but then the include path would need to be the parent directory of the library, which is rather unclean again.
Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?
Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?
There seems to be no need to in this case. You can simply use -I/path/to which makes /path/to/library/headername.h available under library/headername.h.
That said, while there is no such compilation option (that I know of), you can create such "aliases" to file paths in most file systems. These aliases are called symbolic links. In this case, you could make a link /path/to/library/mylibrary that points to . which would make /path/to/library/headername.h available under mylibrary/headername.h assuming you've used -I/path/to/library.
At least on unixy systems, when you compile and install a library, headers are installed for example to
/usr/lib/libraryname/*.h
Or maybe something like
/opt/libraryname-1.2/include/libraryname/*.h
And then if necesssry (not installing to compiler's default include search path), right dir is added with compiler option, for gcc for example option
-I/opt/libraryname-1.2/include
Then just always do this in source code, trusting build system to have included the right search paths:
#include <libraryname/includefile.h>
I'm pretty new to programming and want to use opencv2. I've got a code package and want to run it. It is written in C++ and I want to include several files within opencv2 and the code is:
#include "opencv2/core/core.hpp"
#include "opencv2/highgui/highgui.hpp"
My question is why didn't #include give the whole directory like /usr/local/include/opencv2/...?
This code could not run on my computer because I didn't add opencv2 into my include path.
What should I do?
If your compiler does not automatically look for headers under /usr/local/include, then you need to tell it to do so:
g++ … -I/usr/local/include … source.cpp
The reason that you don't put the full path name into the source is that it makes it unportable. You have OpenCV2 installed in /usr/local, I have it in /opt/OpenCV2. The source would have to be hacked horribly if the code said:
#include "/usr/local/include/opencv2/core/core.hpp"
The way it is, people can locate the OpenCV2 library and supporting headers in any location and only have to specify that location on the command line (or in the makefile, or let an auto-configuring tool do the work for you).
Add OpenCV2 into your include path.
You can write an absolute path into your #include directive if you want, but it's sorely frowned upon as it makes your code utterly non-portable.
In the following files:
app/main.cpp
app/config.hpp
app/show.hpp
app/file.hpp
lib/append.hpp
lib/clear.hpp
lib/reopen.hpp
lib/crypt.hpp
I have a problem. Imagine a few of my files use lib/crypt.hpp. For example in app/file.hpp I should write:
#include "../lib/crypt.hpp"
If I take this file to lib folder it does not work anymore. So I need a something like:
#include "LIB/crypt.hpp"
So, this LIB/ has meaning of (empty) in lib directory while it has meaning of "../lib/" in app directory.
Then I will have no worry about moving file.hpp from app to lib. I just need to fix the callers of it. But not what it calls.
Similar to concept of web programming frameworks. Is it possible in C/C++?
According to what you wrote you're searching for a way to move your sources around without worrying for hard-coded paths to your headers.
You didn't specify the compiler you're using so I'm not focusing on a specific one, anyway most C++ compilers have an option to specify one or more header search paths (on gcc you would just use something like -Ilib_parent_dir).
Once you've included your lib's parent path to the search list, you can move your sources around (as long as you don't move lib's headers) and have them include the right headers with something like #include <lib/crypt.hpp> (and keep include paths priority in mind)
This should be a cleaner and simpler way to achieve what you asked rather than using a macro.
Somehow this is the first time I've ever encountered this problem in many years of programming, and I'm not sure what the options are for handling it.
I am in the process of porting an application to Linux, and there is a header file in one of the directories that apparently has the same name as a header file in the standard C library, and when "cstdlib" is included from another file in that directory, it's trying to include the local file rather than the correct one from the standard library.
In particular, the file is named "endian.h", which is trying to be included from /usr/include/bits/waitstatus.h. So instead of including /usr/include/bits/endian.h it is trying to include ./endian.h. makes no difference
Is my only option to rename the endian.h in the project to something else, or is there a way that I can force the compiler to look in the same directory as the file that it's being included from first?
Edit:
Okay it was just a stupid mistake on my part. My Makefile was setting -I. , so it was looking in the current directory first. D'oh.
There is an important difference between:
#include "endian.h" // Look in current directory first.
And
#include <endian.h> // Look in the standard search paths.
If you want the one in the current directory, use the quotes. If you want the system one, then use the angle brackets. Note that if you have put the current directory in the include path via the "-I" flag, then both might resolve to the one in the current directory, in which case you shouldn't use "-I" with the current directory.
If you include the file with "" instead of <>, the header should be first looked in the same directory as the file including it.
But if possible, renaming the file is much better IMHO: it will avoid problems if files are moved, when you change your build system, etc... The "" vs <> is compiler dependent, also (it is NOT mandated by the C standard to behave as g++ does).
Maybe you can look at the "-I" and "-I-" options?