CFamily - keil preinclude option


(Peter) #1

I am using the commercial SonarQube CFamily plugin scanner with build-wrapper-win-x86-64.exe to analyse a C project. The build uses keil (armcc) toolchain and in command line I specify extra header files to include in every source file with “–preinclude=filename.h” option. I have a problem because sonar doesn’t recognize the definition in that header file and report:“SOME_DEFINITION may not have been defined yet, and should not be used unconditionally”
I have tried to compile the same project with gcc and specify extra header in command line with “-include filename.h” and sonar recognized the definition inside that header file.
Any suggestion how to resolve the issue with keil compiler?

(Loïc Joly) #2

We are supposed to handle this command line option, so something fishy must be happening. Could you send us a small sample that reproduces the behaviour that you encountered?

(Peter) #3

I have prepared a minimal sample that doesn’t work.
if I compile “make sonar_arm” I have an issue “TEST_1 may not have been defined yet, and should not be used unconditionally” in file main.c line 14
I have no issue if I copy main.c in root directory and compile from there “make sonar_arm_working”
and I also have no issue if I compile with gcc “make sonar_gcc”

(Loïc Joly) #4

Thank you for this sample. From what I’ve seen, this is indeed a problem of include folder. With gcc, we consider that the -include file is in the current folder, while with armcc when there is -preinclude file.h, we do as if the C file contained a #include "file.h", so we look in the same folder as the main file

I’ve created a ticket to correct this issue. Meanwhile, I can see several possible workaround (not tested):

  • If you add to your build command a -I path_that_contains_the_header, it should work correctly
  • Same if you specify --preinclude=full_path_to_file
  • Or maybe you can move on of the file so that both are in the same folder…

Tell me if one of those worked!
Thank you!

(Evgeny Mandrikov) #5

Before any correction this must be investigated with a real compiler, because our current implementation seems to be consistent with documentation - :

(Peter) #6

Thank you for answering.
I have added to our build command a -I path_that_contains_the_header and it worked