Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
5 years ago.
#include path uses incorrect search
I have a C++ file that has the following line in it:
#include <time.h>
I expected that the Mbed_cli compiler would find the system file called "time.h" but it found a file with the same name two levels down in my source tree. If I had wanted that file I'd have used
#include "time.h"
Is there a way to control how mbed_cli searches for #include files? It does not seem to be looking if <> or "" are used
1 Answer
4 years, 7 months ago.
I've found a workaround for this problem in our codebase. If you add your local source files to a .mbedignore file at the root of your source tree, the directories will no longer be added to the .includes_ file and the issue goes away. For example, if your files are in a folder called "my_source":
echo "my_source/*" > .mbedignore
Sorry, turns out this has the unfortunate side-effect of no longer compiling the code in my_source either, so it's not really a fix! I've filed https://github.com/ARMmbed/mbed-cli/issues/917 to see if anyone else has a better idea!
I'm running into the same problem, and while I haven't found a solution for this yet, I do have a bit more information. From digging into the actual command line, the following argument is passed: @./BUILD/DISCO_F746NG/GCC_ARM/.includes_18349b8ce7da3e19df69aba86e441bb6.txt Looking inside this, it's a list of '-I' includes for apparently all the folders and subfolders of the current source tree. This seems like a bug, since that means any local user files will be picked up by the compiler in preference to the compiler-provided versions.
posted by Peter Warden 29 Aug 2019