target_include_directories in CMakeLists

After converting project from uVision to csolution and trying to build from VSCode I run into an issue with some source files not compiling.

When looking at the source file in VSCode, the intellisense part indicates nothing wrong with includes, but the compilation fails with " error: use of undeclared identifier "

Manually checking indicates no issues either...

When looking at the list of include directories supplied to armclang.exe however, I see a huge list of include directories that are not relevant for the source file in question.

In most cases this doesn't matter, but for this one, doing this creates conflicts between some headers from different suppliers which results in the compilation error.

I do not know why the build system decides to include paths to all directories where header files are stored when this is not how it works with uVision in which I had no problem.

It also makes no sense to me why the command line shown includes multiple instances of some flags
For example this...
--target=arm-arm-none-eabi -mcpu=Cortex-M33 -mfpu=fpv5-sp-d16 -mfloat-abi=hard --target=arm-arm-none-eabi -mcpu=Cortex-M33 -mfpu=fpv5-sp-d16 -mfloat-abi=hard --target=arm-arm-none-eabi

Parents
  • Having multiple headers with the same name visible inside a single build is a recipe for desaster any way you look at it --- the problem may remain mild ones if they have the same content, or serious ones once these copies start to drift apart, and certainly massive ones if they're totally incompatible to begin with . 

    The only good solution is to strictly never allow that to happen.

Reply
  • Having multiple headers with the same name visible inside a single build is a recipe for desaster any way you look at it --- the problem may remain mild ones if they have the same content, or serious ones once these copies start to drift apart, and certainly massive ones if they're totally incompatible to begin with . 

    The only good solution is to strictly never allow that to happen.

Children
  • After a bit more digging around, I see that
    #include <errno.h>
    which is meant to include the standard library errno.h file is instead including the lwip version of errno.h
    This lwip version of errno is NOT supposed to be used as it's not in the include paths defined in the project.

    I still do not know why the build process decides to include paths to ALL possible headers in the project when only specific paths are requested in the project file.