I have two projects in an eclipse workspace and one will add the include path for the boost libraries and one will not.
both projects use -std=c++11 I have included the include path in the c++ settings for both projects and it will not show up in the Includes section of one of the project. I have no idea where to look to resolve this issue.
I can include other include paths and they work as one would expect. I think it must have something to do with the boost libraries but I have no idea what to look for.
Any suggestions would be appreciated.
I just created a new project and copied all of the files over and it works perfectly, it must have been some problem with the project. Sorry for the bother.
Related
I have an issue with custom libraries that reference headers in other custom libraries.
This is under Eclipse (2020-03) with the 9.11 CDT - Arduino Plugins. (So the latest Version at this time)
Until now I have been using Sloeber, which included all include paths from all custom libraries so everythig was building fine. But with the latest Eclipse/CDT version sloeber does not work anymore. Since it should not really be necessary anymore anyway, I am trying to get my projects to build with just the CDT-Arduino Plugin(s).
Simple projects are Building fine, but more complex have issues…
The build process (makefile generation) seems to scan though the libraries directory, because I can see all the entries in the makefile to build the things it findes in there. But I one of these libraries referneces a header of another one it failes to find it.
Of course I could just edit the include and make it relative, but since these are imported libraries I prefer not to make changes in the code.
With the Arduino plugin there is also no configuration for include paths etc in the project properties any more :-( Normally I would have added the include path there, but the arduino Plugin seems to want to do it all by itself...
Any idea, how I can add the required include paths? Is there a way to do this in the makefile.ini?
I found a different and better way to add custom libraries, which also solves the include path problem. Sadly there is no documentaion about this.
Anyway, it is very simple, just copy the library to the …/.arduinocdt/libraries/ folder. The custom library must contain a library.jason and library.properties file. When opening the Arduino download manager, you can see the new lib and ýou can add it.
Eclipse will read the library version from the json/properties and copy the data in the correct form in a sub directory with the version number.
For libraries added this way, all includes/headers will be found without Problems including libraries referencing other libraries.
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.
I am developing using OpenSceneGraph. I installed it from a user-runnable installer.
When I try to compile an application using OpenSceneGraph, I have this error :
Lexical or preprocessor error : Include cannot be found for all <osg/*> includes like <osg/AnimationPath>.
The file is available here /Library/Frameworks/osg.framework/Versions/92/Headers/XXXX So following this solution on how to "add existing frameworks" to the new Xcode, I added osg.framework to the project.
any idea is a welcome.
I am using :
IDE Xcode 4.5
Clang 4.1
OS X Mountain Lion
When compiling you will have to add the include files using the -I option of the compiler and also possibly add library directory using the -L option of the compiler(the options may be a bit different if you are using compiler different from gcc).
I guess both library and the include directories for this product should be subdirectories of the install destination you have chosen. For the include directory of course look for directories containing some kind of header files .h or .hpp and for the libraries look for .lib or .dll doesn't the library documentation mention what includes and libraries you need and where you can find them?
EDIT: you will also have to tell xcode where to search for your includes. I tried googling it and here is one of many results on how to add a directory to the include path of a project.
You will have to located which directory to add to the include path. It seems they set some environment variables in the official documentation for that.
Hope this helps.
You'll need to add /Library/Frameworks to the "Frameworks search path" in the project settings.
say I have a sln which contains 10 projects(named proj1 to proj10), and proj1 is the default project which generate the EXE file.
My problem is: how to place the 'include' folder?
I mean if proj2 uses proj3(that is including its header file and linking its lib file), how to place the 'include' folder?
there are two approaches:
place all header files and lib files in a different root folder which is in the same level of the project
make every project self-close, and the other projects who want to use this project should take care of the include-path and link-path. Of cause we should give a rule to the layout of every project(e.x. every project MUST have a 'include' folder and 'lib' folder in the root folder)
any suggestion?
thanks
When it comes to Visual Studio, I don't like either of the two approaches you suggested, although mine is most closely related to your Option #2. The way I like to organise it is like this:
<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln
In case that's not obvious, that's a quasi-directory listing showing some project folders and the base solution file.
All new projects are just added to the solution using Visual Studio's default settings. Trying to go against this and making projects work like Linux projects (lib, include, src etc) just ends up causing you grief, so don't do it.
Now, I set my "additional includes" path on every project to $(SolutionDir). Then if I want to include something from Project1:
#include "Project1/someheader.h"
The advantage of this is you don't clutter up your 'additional includes', so it's easy to see at a glance what external includes a project has.
As for linking to lib files, why not take advantage of Visual Studio's project references feature. Honestly, your life will be easier. Simply hook it up so that Project2 references Project1, etc... Then you don't have to worry about libraries and linker paths. You only do that for toolkits that are outside your solution tree (eg distributions such as libpng or openssl).
Again, you free up that setting so it only shows linkages outside of the solution. The other advantage is that your build order is implicitly defined if you use references.
I would go with the 1st solution. it make the project settings simple. As the C++ projects we worked on, we always put the header files together.
for example I need to include a header
#include <OpenGL/glext.h>
while it is actually a header file glext.h under OpenGL.framework/Headers/.
Therefore it is no way to give eclipse a physical path about "OpenGL/glext.h", and I always get unresolved inclusion warning.
I can still build and run them (with managed makefile project) but it is impossible to browse the functions or definitions from those "resolved" header files.
is there any solution?
While not ideal, my solution to this has been to create a folder "/Developer/Framework Headers" (though the name isn't important), and link from e.g. "/System/Library/Frameworks/Foo.framework/Headers" to "Foo" under said folder. Then in Eclipse I add "/Developer/Framework Headers" to a project's includes.
I say not ideal because apart from having to create links for the frameworks you need and add an include to each project, Eclipse seems to have trouble in certain cases such as nested frameworks (e.g. CoreGraphics beneath ApplicationServices), but YMMV.
Yes there is one. Right click on the project in "Project Explore" window and click on the "property". In there Open "C/C++ General" column and choose "Path and symbols". Now you see all of the include library path for this project. If your using C then add the OpenGL library into GNU C, or if you use C++ then add it into GNU C++. Unfortunately you have to do this for every new project. I have been searching for a while how to do this by default but nothing really useful. Hope this help you get rid of those annoying yellow wave lines.
Since current Eclipse CDT releases don't perform sub-framework header inclusion correctly, you can avoid sub-framework problems (like those generated by the CoreServices header files) by creating symbolic links to the include directories of each sub-framework. I elaborated on this subject, which stems from danhan answer on this question, in this blog post.
In order to automate this process, I've created a Z shell script which automates this process and creates the symlink to the specified frameworks' header directory, together with the links to the include directory of each one of their sub-frameworks. The script can be found in this GitHub repository.
Hope this helps.