4 years, 5 months 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

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

1 Answer

4 years 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!