I’m having pretty strange include issues.
The package I’m trying to compile is based that the base folder to look for files is where the original source is.
I’ve got a folder (we’ll call A) in the component folder with several folders below that (B, C and D) with .hpp files in those. The #include is written so that the start point would be in the directory where A is. The weird thing is that D.S. finds the first include called out by a CPP file that is in say folder B. B then includes another include file that is in folder C (#include “A/C/file.hpp” which is correct as that’s from the original component folder. However, it can’t find it. I’ve tried putting in …/…/ in front of that and sometimes that works, and sometimes it doesn’t. Additionally, I’ve tried putting in the cdef file cxxflags{ -I…/…/} but that doesn’t work either.
Please could you share a sample structure to highlight your point?
The thing is that DS Include folders settings are not synchronized with the cflags definition of the component.cdef. We’ll study the possibility to do this in a future version.
In the meantime, you’ll probably need to check the Include settings in the project properties in order to make the editor happy.
Thanks @daav for responding.
I’m sorry, I said a D.S issue. This isn’t an editor issue, it’s a compiler issue.
Component Folder
A include folder
B include folder C include folder D include folder
1.hpp 3.hpp 4.hpp
2.hpp 5.hpp 6.hpp
So in the .cpp file it has: #include “A/C/5.hpp”
And in 5.hpp it has: #include “A/D/6.hpp” This errors out saying it can’t find 6.hpp.
It’s like it’s starting in a different spot now. But I can’t seem to find the right relevance to get it to compile. The only way I can get it to find the file is put it in the .cpp file and take it out of the .hpp file.
I don’t know if this is relevant, but for some reason now, it will only try to build “release” builds. I can change it to Debug, but when I go back to look, it’s still release. I even went so far as to change the settings.pref file in the project, and then relaunch the DS. But when I check, it’s back to release. Is it possible that something has gone wrong with my DS?
Hi @daav,
So, I figured out what the issue is. I can’t seem to get the compiler to look in the same directory as the source directory for #includes that come from another #include file. All my attempts (turning on verbose mode) yield “Ignoring non-existent directory…”. I’ve tried full paths, relative paths and nothing seems to work. So I put the project into the Linux version, and it compiles fine once I add the path and figured out how to set c++11 mode, which seems to be different than the Windows version. I’ve never seen a compiler that doesn’t automatically add the source path as a search path for includes.
I have tried adding the path in the “Paths and Symbols” in the properties windows, both as a project directory and an absolute directory, It says the directories don’t exist. There seems to be a bug in the project one though because it comes out with no separators.
Hi @daav,
I finally had to just move the include folders that I had in the component up a directory (because the app directory is part of the includes folders), and that works. But that’s not idea in any case.
I should be able to add my component folder for an include start point. Is there a way to do that?
by default, both the app folder (the location where your adef is) and the component folders (the locations where your cdef files are) are on the include path.
Then, if you want to play with header files in other directories, you should:
either deal with paths in #include directives (what you tried to do above).
The important thing is that relative paths are relative to the current file. So when you include a header from another header, path has to be thought relative to the including header.
e.g. for your case above, to get 6.hpp included in 5.hpp, the include directive in 5.hpp needs to be #include “…/D/6.hpp”
or you can deal with paths in the settings, which means:
To make the build functional: add the relevant options in the cflags/cxxflags sections. Note that paths relative to $CURDIR variable (the folder of the current adef/cdef file) should be prefered, because espacially on Windows, paths need to be translated between Windows file system and Docker container point of view… What I mean is that absolute paths will definitely not work on Windows.
To make the IDE Indexer happy: add the relevant Include path in the project properties. This is optional as this won’t break the build if you don’t do that, but you’ll get unresolved includes and semantic errors in the IDE.
I hope it makes the things a bit more clear.
If you still need help, please can you consider attaching a zip containing a project that is not working for you? This will greatly help for accurate support.
@daav,
Thanks for the reply. I did get $CURDIR to work. Thank you! I made a work around where I put all the folders up one directory and that worked. All I did was add -I$CURDIR to the cxxflags and it worked.
Like I said though, I’ve never seen where the #include folder is relative to the current include. I remember trying a relative path (taking off the directories) for one of the includes to see if it would find the file in the same directory it was in, but that didn’t work either. Really unclear what the distinction is.
One issue I did find was when I was adding -I$CURDIR to the cxxflags in the .cdef file, the DS went out to lunch and wouldn’t take anymore characters. I had to kill it and restart it. I tried it 2 more times, just to make sure. The 3rd time, I typed: -ICURDIR, and then inserted the $. No problem there. Must be some sort of live eval going on that seems to lock up the DS when you just type in -I$.
Hi @EvetsMostel
Yes, there is a bug as soon as you type a $ in the editor. We’re looking at it.
Workaround: copy-paste the $ character from elsewhere; or insert it after having written the variable name, as you found.
Yes I know.
5.3.1 only includes few patches to get compatible with Legato 18.01, but it is mainly the same than 5.3
The plan is to try getting this fixed for DS 5.4