I have a project whose vcxproj file is auto generated prior of compilation by using a script during the build process.
this project dependes on a boost library which is installed in a known location on the build machine.
the project header file declares:
#include "boost/foreach.hpp"
which forces me to manually add the path to the boost root folder to the Additional Include Directories field in the vcxproj file.
As the project file is auto-generated it forces me to split the build process into two stages and edit the project file in between.
i have also tried to change the source file and add the full path in the #include statement:
#include "<path to boost root>/boost/foreach.hpp"
but then some boost internal include fails. Which means i can't proceed in this way.
I have read through Set #include directory from C++ code file to find there is no option to add the path from code.
As I'm now on VS2012/C++11 environment i wonder if anything changed in VS2012 / C++11?
Is it still impossible to add an Include directory using a code statement?
You mean dynamically? No, there is no way. The reason is simple:
When you are running your program, it's already compiled, hence the compiler has to know about all the files to include at compile time.
It seems you're using CMake. If that's the case, I recommend you to add the include dirs in the CMake file.
Firstly, doing this:
#include "<path to boost root>/boost/foreach.hpp"
should be strongly discouraged. By doing that, you're making your source code build-able only on your environment - as your project grows, it will be a nightmare to change the path, or for other developers to build it. And, as you discovered, you'll break any headers which are included further down the chain, which are using relative paths.
What kind of script is generating your project? Is it a custom one, or is it a well known build tool such as SCons or CMake? The correct solution is to fix your build script so that it generates the project with the additional include paths correctly.
Related
I am using bazel to build a c++ application that includes protocol buffers. This means that bazel runs the protocol buffer compiler as part of the build process, and squirrels the generated files away somewhere within the bazel output directory. VSCode is then unable to resolve these #include directives since they are not on any include path that vscode knows about.
But I'd rather not hardcode some frequently-changing bazel output directory in my vscode config. Does anyone have any suggested strategy for resolving this?
You can hardcode <bazel_workspace_path>\bazel-genfiles or <bazel_workspace_path>\bazel-bin as include directories.
bazel-bin and bazel-genfiles are junctions (~= directory symlinks) that point to the corresponding output directories. (They are called convenience symlinks. See the --symlink_prefix flag for more info.)
This was an issue we've been dealing with for a while now - we're building a C++ project using the Cygwin toolchain, and no matter what we add in the C++ compiler include paths under project settings, Eclipse can't seem to find the necessary header files.
We have done everything the Stackoverflow community has suggested so far;
Made sure include paths were workspace-relative
Tried backslashes and forward slashes
Tried using Cygwin-specific paths (/cygdrive/c instead of C:/)
Checked the compiler output to verify include paths are there
Checked the generated makefiles to make sure they're correct
Rebuilt the index
Deleted the debug folder entirely
restarted Eclipse
Basically nothing short of changing the #include <...> code itself to use a full path (C:/.../file.h) worked. This doesn't work for our needs as we need multiple developers to be able to work on this project, and the files themselves are generated dynamically as a result of some of our build procedures.
So here's a fun little detail about Eclipse we didn't know - specific source files themselves can have their own settings.
If you look at your source files and see the following wrench icon, this means that file has some settings which may be contrary to your project-specific settings.
As a result, our source-specific settings were overriding the include paths, so for those files, none of the headers could be found. The best part is that Eclipse doesn't tell you in any way more explicit than this - the wrench icon does not offer a tool-tip to explain what's going on.
Simply right click on the file > go to Resource Configurations > Reset to Default...
Your header files will be found now, provided that you've written the correct include paths in your project settings.
For reference, we're using Eclipse Kepler - I'm not sure if they fixed this and added more info for users in newer versions.
After importing a c++ Makefile-project into Eclipse, my project depends on some libraries which are located in /usr/include/gazebo-2.2/gazebo.
These are included via the line #include < gazebo/xx/xx.hh>. CMake doesn't have a problem finding the files, Eclipse unfortunately does...
In my include folder, the folder /usr/include/ is set as include path. However it can't find the include files.
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Is it possible for eclipse to discover the files without adding the full path to the include directories?
Since you are using a Makefile project, presumably your makefile specifies the relevant include path. Eclipse can pick this up using its Build Output Parser. The general way to set this up is:
Make sure your makefile can produce output that includes the full compiler command invocations (e.g. gcc -I /usr/include/gazebo-2.2 ... - since this is what the build output parser needs to see), or can be configured to produce that output.
Make sure Eclipse is configured to invoke your makefile correctly (in terms of invocation directory and target name) in Project Properties -> C/C++ Build.
Make sure the build output parser is enabled in Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers tab. If necessary, adjust the "Compiler command pattern" as appropriate.
Perform a build from within Eclipse. Assuming your build is successful (or at least succesful enough for the build output to contain the compiler commands for every source file), the build output parser should then pick up information such as include paths and macros defined on the command line. In the Project Explorer, source files for which settings were picked up in this way will be annotated with a little wrench decoration on the icon.
At this point, your includes should be resolved. You may need to re-build the index to get Eclipse to process the contents of the newly resolved files.
For completeness, since you mentioned CMake, I'll mention that there also exist plugins that will configure a project's include paths directly based on CMakeLists.txt. (I can't recommend a specific one because I don't use CMake myself, but searching for "CMake" in the Eclipse Marketplace should give you several options.)
Is it possible for eclipse to discover the files without adding the full path to the include directories?
No, not unless the include path in question is one of the compiler's default include
paths, which is not so in your case.
If your want the compiler to find the header file referred to by e.g.
<gazebo/xx/xx.hh>
when the required file is:
/usr/include/gazebo-2.2/gazebo/xx/xx.h
then the compiler must be given the include path:
/usr/include/gazebo-2.2
which should appear in compiler commandlines in your build log as:
-I/usr/include/gazebo-2.2
I notice also that your example is actually:
#include < gazebo/xx/xx.hh>
not:
#include <gazebo/xx/xx.hh>
In your example, the leading space will be considered part of the
filename and the header would not be found.
I have code that must be shared between two executables in the same project (one build command will build them both). This code contains #ifdef preprocessor statements which change how it works in each project (a command-line macro definition is used as a switch).
The source is abstract in the sense that some headers are missing. For example, the shared file Application.cpp might include a file called gui/MainWindow.h which doesn't exist int he shared directory but does exist in the executable source directory. Or it may include a file called gui/Local.h that does exist in the shared directory.
Essentially I need the gui path to be a combination of two locations.
On unix I've done this before simply by setting up a series of file links, but this project now has windows as a target (Visual Studio). Also, I am aware of how to do this using a shared directory structure and setting compiler include switches, but I'm hoping there is a simpler way.
Any ideas?
I use CMake for the build generation and GCC and Visual Studio as compilers.
I've already looked at defining a directory for the preprocessor, but the #include directive unfortunately cannot combine several tokens to create a filename. A single name works, and this might be an option to have cmake spit out macros for all the shared file names.
I really think the simplest solution is to use include paths - have different paths for the different projects. Look at property sheets to share settings between projects and greatly simplify the management.
If you are using file links in unix, you could do the same in Windows with symbolic links.
How do I properly include libraries in C++? I'm used to doing the standard libraries in C++ and my own .h files.
I'm trying to include wxWidgets or GTK+ in code::blocks and/or netbeans C/C++ plugin. I've included ALL libraries but I constantly get errors such as file not found when it is explicitly in the include!
One error: test1.cpp:1:24: wx/msw/wx.rc: No such file or directory : Yes the .h file library is included; what am I missing?
Do I need to be importing other things as well? Is there a tutorial for this? Obviously my shoddy textbook hasn't prepared me for this.
Firstly, header files are not the same thing as libraries. A header is a C++ text file containing declarations of things, while a library is a container for compiled, binary code.
When you #include a header file, the compiler/IDE needs to know where to find it. There is typically an IDE setting which tells the compiler where to look, or you can do it from the command line, normally using the -I switch. It sounds to me as if you have not set up the path to search for header files on in your IDE.
This means that test.cpp included "wx/msw/wx.rc" but that file cannot be found by your compiler. How to fix this depends on your compiler, but you need to find where wxwidgets is installed and add that to your "Include Paths" so that your compiler knows where to search for it. You can also put a more complete path to it in the include directive.
If the files are present in the same directory as test1.cpp, then probably you use the wrong kind of include. #include <...> is usually used for code that resides outside of the directory that your project is in. #include "..." is for includes inside your project directory (and then if they aren't found there, search in the same places as #include <> would).
It is quite an old question and this didn't really answer it for me.
I reinstalled wxwidgets into the root directory as someone suggested that being in a directory with a space in the name may be part of the problem.
Then I went into project > build options > search directories and removed all entries pointing to original install.
And this fixed the problem