I have a project which is built using cmake.
This project is uses avr-gcc to compile the binaries and I use boost mpl for some parts of it.
As avr-gcc does not have /usr/include as a default include path but boost is installed there, I need to add it as an include path such that boost is found.
Unfortunately, adding -I/usr/include to the command line pulls in all other files and directories in /usr/include which seems to introduce collisions with the avr includes and thereby compiler errors.
My initial solution involved a softlink to /usr/include/boost in one of my user defined include directories to resolve the
#include <boost/mpl/*>
However, I thought this to be not very platform independent and decided for cmake to add the include path for boost. This again led to "-I/usr/include" being present on the compiler command.
How do I solve this in a platform agnostic manner?
A solution would be to let cmake create the link for me to get the right include directory.
However, I consider the whole symbolic link solution ugly.
Is there something better that I can do?
For example: Is there some option that adds an include path under an alias like:
-I/usr/include/boost:boost
Which would add only the boost subfolder under the name boost to be includable by the #include <boost/...> directive?
I see at least two options for you:
Where does avr-gcc include files from by default? Let's say it is /opt/avr-gcc/include for concreteness. Then what may work for you is -I/opt/avr-gcc/include -I/usr/include.
Another option is to install Boost in a different directory and use that instead of the Boost in /usr/include. For example, you might create /opt/boost and then use -I/opt/boost (or a sub-directory under that) on the command line.
Related
Is it possible to configure a Bazel custom toolchain to include directories in the repository?
Assume that I have following in the root of my repository:
sysroots/armhf/include/myheader.h
sysroots/amd64/include/myheader.h
myproject1/component.cpp
myproject2/component.cpp
I'd like to configure toolchain such that when I run bazel build --config armhf, component.cpp files including myheader.h would get the header from sysroot/armhf/include directory, and when I run bazel build --config amd64, file from corresponding sysroot/amd64 directory were used.
This needs to work without having to modify projects containing component.cpp files.
Essentially I would like to check in platform specific headers and binaries in the source repository along with the code.
If you haven't found it yet, you need to write C++ toolchains. The Configure C++ Toolchains Tutorial is a good place to start, if you have more specific questions they'll get better answers as separate questions. I'm going to answer specifically about the paths here.
Most of the paths are just normal paths relative to the execution root. That typically means external/<repo_name>/<package>/<name> for paths in external repositories, or just <package>/<name> for paths in the main repository. bazel-toolchain's pkg_path_from_label function implements this logic, for example. In your case, that's sysroots/armhf/include for the first path.
cxx_builtin_include_directories is special. Paths there have unique syntaxes to generate absolute paths. The relevant one looks like "%package(#your_toolchain//relative/clang/include)%", with #your_toolchain replaced with your repository's name. In your case that means something like "%package(#//sysroots/armhf)%/include/myheader.h". Depending on where the package boundary is (deepest folder with a BUILD file) more or less of that might need to be in the %package() part.
Those directives get expanded when generating compiler command lines. I'm not aware of any documentation besides the source.
I have a C++ project that needs to be built with CMake and MinGW-W64.
Some libraries (such as zlib, libpng) are in: C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32\
So I use : -DCMAKE_PREFIX_PATH="C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32"
But, I get a compilation error because the following header is outdated and miss important symbols:
C:\Dev\mingw64-5.3.0\x86_64-w64-mingw32\include\float.h
If I add a compiler flag to search into the proper include directory for float.h:
-DCMAKE_CXX_FLAGS="-isystem C:/Dev/mingw64-5.3.0/lib/gcc/x86_64-w64-mingw32/5.3.0/include"
Then, this does not work, since CMake will add this folder after its generated includes_CXX.rsp
How can I handle this issue? Is there a way to enforce header search path priority?
You could also add the include location(s) to environment variable C_INCLUDE_PATH and CPLUS_INCLUDE_PATH.
To locate the libraries you can do the same for the lib with the LIBRARY_PATH environment variable.
For DLL and EXE files you may even need to add the bin path to PATH.
I use 2 different GCC versions on the same CentOS machine (included in OS one and custom one), and I don't want to replace system GCC with my custom one, I use custom one to build some software only.
The problem is that Qt Creator adds /usr/include to include folders automatically, so custom GCC starts to use system C++ includes and crashes with strange error messages like error: '::memchr' has not been declared. I don't have /usr/include anywhere in my *.pro file, so it looks like Qt Creator adds them itself.
How to prohibit Qt Creator project to use some specific include patches to allow compilation on machine with 2 GCC versions? When I use Eclipse CDT on the same machine, it works excellently, because Eclipse doesn't add anything itself and only uses include directories specified by me.
You can use CXXFLAGS += -nostdinc.
This should do the following (excerpt from the manual):
Do not search the standard system directories for header files. Only the directories you have specified
with -I options (and the directory of the current file, if appropriate) are searched.
It is not elegant answer, if someone has better ideas, you are still welcome to post your answer and I'll accept it.
So, I added custom build step between qmake and make commands, and I use sed command in this custom build step to edit Makefile on the fly and remove extra includes. This solution works, however, it is ugly.
I had no problem with Allegro while using Linux, but I can't figure out how to include the library on OS X. I built it from source originally, but I uninstalled it to try the MacPorts version. The headers are currently in /opt/local/include/allegro5/.
I can't use #include <allegro5/allegro.h> or
#include "/opt/local/include/allegro5/allegro.h".
Based on the compile errors, I think the Allegro headers reference each other by
#include <allegro5/other_header.h>.
So how do I add the allegro5 directory to the include path for gcc/g++?
Thanks!
Based on the data in this post, it looks like the correct include path is /opt/local/include. When gcc/g++ attempts to #include <allegro5/allegro.h>, it will add that relative path to the base include paths in its list in order to eventually form the string /opt/local/include/allegro5/allegro.h where it will locate a proper file.
If you're compiling via command line with gcc/g++, add the option -I/opt/local/include. If you're using Xcode, well, I'm not so familiar with that, but I'm confident that you would need to dig around in the project's settings and find a UI widget that allows you to add additional include paths.
I am adding extensions to an (another persons) existing project at my company. Now I want to import an existing library like boost to it. I am using netbeans for debugging the existing project. Now in order to import a library into netbeans usually 2 steps are followed:
Include directories
Linker-> Add Library.
However when I right click on my existing project the option of Linker->Add Library is not appearing. (Though I have included the directories as that option is there).
Can someone please guide me as to how should I add the library through linker to my existing project? My project is in C++
Assuming you are using unix/linux variants:
Directories for headers and library linking are two different things. Include directories will have the headers needed, but after compilation the actual compiled code that resides in the libraries (*.a, *.so, etc...) might also be required.
For example, if you are using pthreads, apart from the headers which you need to include, you also need libpthread.
When linking, you need to provide the flag for linking with pthread i.e: -lpthread
You can search using find or locate on a unix system to find the libraries. In my case, its in
/usr/lib/libpthread.so
Therefore,
gcc myfile.c -lpthread -o myfile
Will link myfile.c with pthread library
Whereas,
gcc -L/usr/local/lib/
Tells gcc to look under /usr/local/lib to search for the library (not the header!).
Telling netbeans where the headers are, isn't enough, it will probably give you linking errors. Telling netbeans where the libraries are, may be enough, as it might use the proper flags. If that also fails, then you have to specify both the library flags and the path.
Alternatively, you may use tools like cmake, make, etc which automate this process and provide a bit more control IMO.
See Link 1
See link 2