Certain tools (bazel) produce such an output, where absolute paths cannot be used in a cross-environment way. Absolute paths in the .plist output make the CodeChecker store and diff commands unusable as (for example the Bazel) cache folder prefixes would not allow the proper identification of the source files.
A dedicated flag should be added to the CodeChecker analyze command, which would enable the option of the use of relative paths during the whole CodeChecker workflow.
I propose the --use-relative-paths flag for the function mentioned above.
analyze:
When using the analyze command with a compilation command, that contains "."
The current implementation defines the meaning of the relative directory in the compilation database in the following way:
If the "directory" is a "." CodeChecker will pass the current working directory to the exec() function call in the cwd parameter. Eg. the actual analysis command will be executed from the CodeChecker analysis invocation location.
We had an issue with the passing of a filename with leading path elements in the –file option.
#4180 Should fix the problem with the --file option.
When the --use-relative-paths flag is active, all of the paths should be considered, and resolvable from the original CodeChecker analyze invocation, in every output format.
Considering the following directory layout:
/home/proj/src/source.c
/home/proj/src/include/header.h
/home/proj/reports/
/home/proj/reports/proj.plist
Example .plist
…
<key>files</key>
<array>
<string>./src/source.c</string>
<string>./src/include/header.h</string>
</array>
…
The paths in the .plist file should be relative to the CodeChecker invocation location.
parse, store, cmd, and server:
The support for relative paths should also be added to the report management command line (parse/store/cmd) utilities, and possibly to the server too.
Because the .plist contains paths to the source files relative to the CodeChecker analyze invocation location, the user must invoke the CodeChecker store|parse|cmd from the original invocation location of CodeChecker analyze
/ The command only works if/$CWD=/home/proj/
CodeChecker store home/proj/reports
Certain tools (bazel) produce such an output, where absolute paths cannot be used in a cross-environment way. Absolute paths in the
.plistoutput make the CodeChecker store and diff commands unusable as (for example the Bazel) cache folder prefixes would not allow the proper identification of the source files.A dedicated flag should be added to the
CodeChecker analyzecommand, which would enable the option of the use of relative paths during the whole CodeChecker workflow.I propose the
--use-relative-pathsflag for the function mentioned above.analyze:
When using the analyze command with a compilation command, that contains
"."The current implementation defines the meaning of the relative directory in the compilation database in the following way:
If the
"directory"is a"."CodeChecker will pass thecurrent working directoryto theexec()function call in thecwdparameter. Eg. the actual analysis command will be executed from theCodeChecker analysisinvocation location.We had an issue with the passing of a filename with leading path elements in the
–fileoption.#4180 Should fix the problem with the
--fileoption.When the
--use-relative-pathsflag is active, all of the paths should be considered, and resolvable from the originalCodeChecker analyzeinvocation, in every output format.Considering the following directory layout:
Example
.plistThe paths in the
.plistfile should be relative to the CodeChecker invocation location.parse, store, cmd, and server:
The support for relative paths should also be added to the report management command line (parse/store/cmd) utilities, and possibly to the server too.
Because the
.plistcontains paths to the source files relative to theCodeChecker analyzeinvocation location, the user must invoke theCodeChecker store|parse|cmdfrom the original invocation location ofCodeChecker analyze