Relative include flags with spaces cause parsing failure

[andocz]

When parsing Scintilla 3.10.6, errors like this occur:

/mnt/linux/hg/scintilla-code/lexlib/Accessor.cxx:11:10: fatal error: 'ILexer.h' file not found
#include "ILexer.h"

This is because Scintilla uses spaces in the include flags, like so (in gtk/makefile):

INCLUDEDIRS=-I $(srcdir)/../include -I $(srcdir)/../src -I $(srcdir)/../lexlib

This causes an issue due to the combination of the following two things:

1. CodeCompass_logger doesn't convert include flags with spaces to absolute paths.
2. CodeCompass_parser can only handle absolute include paths.

Removing the space after every -I in gtk/makefile fixed the issue, confirming this explanation.

[mcserep]

Does CodeChecker's logger handle this correctly? If so, can we update CodeCompass' logger with the one in CodeChecker?

[andocz]

CodeChecker's logger keeps the include paths as-is, it never converts a relative path to an absolute one or vice-versa.

I think the proper fix would be to make the C++ parser use the compile command's recorded directory as the working directory when running ClangTool. We shouldn't rely on compile_commands.json to only contain absolute paths. Even if CodeCompass_logger always successfully converted all paths to absolute, other tools may generate compilation databases with relative paths (see CodeChecker).

[whisperity]

I think the proper fix would be to make the C++ parser use the compile command's recorded directory as the working directory when running ClangTool.

This does seem like the right call, but let's ask @bruntib to give us a heads-up related to this issue and what steps were taken in CodeChecker. I have vague memories of issues like this constantly looming around us...