A compilation database is relative to the compilation target. If users want to run cpp-linter on multiple targets, then the feedback is non-exhaustive.
cpp-linter's feedback (thread-comment, step-summary, and PR reviews) is not associated to a commit's SHA by cpp-linter's feedback dismissal/update behavior. So, running cpp-linter multiple times (from 1 commit) for different compilation targets would only show feedback for 1 target.
I'm not sure what the desirable solution for this would be, but it will not be a simple patch. In theory, I think the database option should accept a single string (as it does currently) or a mapping of paths to certain C/C++ sources.
- uses: cpp-linter/cpp-linter-action@v2
with:
# use database in examples_pico/build for files in examples_pico
# use database in build for all other files
database: >-
examples_pico/*.{cpp,h} : examples_pico/build |
./**.{c,cpp,h,hpp} : build
A compilation database is relative to the compilation target. If users want to run cpp-linter on multiple targets, then the feedback is non-exhaustive.
cpp-linter's feedback (
thread-comment,step-summary, and PR reviews) is not associated to a commit's SHA by cpp-linter's feedback dismissal/update behavior. So, running cpp-linter multiple times (from 1 commit) for different compilation targets would only show feedback for 1 target.I'm not sure what the desirable solution for this would be, but it will not be a simple patch. In theory, I think the
databaseoption should accept a single string (as it does currently) or a mapping of paths to certain C/C++ sources.