Recent versions of Bison (I'm using 3.8.2) generate header guards which seem to be based on the absolute path of the generated header file. Since this Bison-generated code will be included in the release tarballs of our project, it is not desirable to reveal absolute paths from the machine where Bison was originally run. Is there a way to control the header guards that are generated?
Related
I am about to start writing a code in C++ for my PhD. Until now I worked with small code. All the files (sources and headers) in one directory.
Since I want to write a more organized code, I'll put files in different directories.
So what is the proper way to include files? Should I use something like
#include "../../folder/file.hpp"
It doesn't look very clean. And is the code portable to Windows if includes are done this way?
is the code portable to Windows
I don't see a reason why it wouldn't be, as long as you fix the syntax of the directive first. I don't have a windows to test at the moment, but that's a valid path.
However, I would recommend to avoid parent directory include paths. Instead, specify a directory as an include directory for the compiler, put all your headers there into sub-directories and include with a path relative to the include directory.
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 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.
Suppose I have a.cpp as a source and I add it to a cmake target:
add_executable(MY_TARG a.cpp)
If a.cpp includes a.h it will be added as a dependency for the target and when I change the header, everything will get rebuilt properly, but a.h won't show up in the list of sources for my project (in visual studio for instance).
Is there a way to add it there?
And can I distinguish between system headers (like <vector>) and headers from a folder from the same directory structure? I might wish to add only headers included with quotes and not with brackets ("header.h" and not <header.h>)
I am looking for something automatic - I already have a lot of CMakeLists.txt files with only .cpp files listed there and going through all of them seems impractical.
It's fairly simple - if you want a file to be listed as part of a project in an IDE, list it as part of the target in CMake:
add_executable(MY_TARG a.cpp a.h)
CMake knows enough to recognize it as a header (and thus not attempt to compile it), but it will list it in the generated IDE project.
EDIT
Based on the added information of looking for an automatic change to an existing system, I don't think that's easy. But it should still be doable. Compilers usually have a way of listing headers included by a file they compile (e.g. gcc has -MM). You should be able to build a one-time conversion script based using this output and your favourite text-processing language.
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.