Do I understand correctly that cppcheck/tools/test-my-pr.py uses two versions of cppcheck source code (installations) to test the exact same Debian source code?
The above helps for testing changes to cppcheck itself, which, of course, is what test-my-pr.py was made to do.
But what about the case where, during normal use of cppcheck, I as a Debian developer (I'm not a Debian developer, just trying to ask the question clearly) want to test two different versions of Debian source code with the same cppcheck source code/installation. Is there any wisdom, third party resources, tools within cppcheck etc. for handling parsing the two cppcheck outputs in order to have reasonable clarity* on:
1. What warnings that used to be present have now gone away
2. What warnings that didn't exist before are now present
By "reasonably clarity" I have in mind things like this: A way to avoid spurious results like a section of coding causing a warning on the first run and then, on the second run, the same section incorrectly being reported as a new warning that didn't exist before... but only because the code surrounding the offending section changed such that the offending section is now on different lines than it used to be on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use a little bash scripting and git blame. If your code is in git repo this might help you. I do this will all CI tools not just cppcheck. The main reason for this is for upgrading CI tools or remove false positives if necessary. So I can push the new version into CI before fixing all the new things it found so that developers get the benefits of the upgrade tool right away. I use git blame -n pared with the cppcheck( or any tools )output. That way I have a list of things that I can filter out of a tools output.
from the git blame man page
-n, --show-number
Show the line number in the original commit (Default: off).
Last edit: john borland 2023-08-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do I understand correctly that cppcheck/tools/test-my-pr.py uses two versions of cppcheck source code (installations) to test the exact same Debian source code?
The above helps for testing changes to cppcheck itself, which, of course, is what test-my-pr.py was made to do.
But what about the case where, during normal use of cppcheck, I as a Debian developer (I'm not a Debian developer, just trying to ask the question clearly) want to test two different versions of Debian source code with the same cppcheck source code/installation. Is there any wisdom, third party resources, tools within cppcheck etc. for handling parsing the two cppcheck outputs in order to have reasonable clarity* on:
1. What warnings that used to be present have now gone away
2. What warnings that didn't exist before are now present
I use a little bash scripting and git blame. If your code is in git repo this might help you. I do this will all CI tools not just cppcheck. The main reason for this is for upgrading CI tools or remove false positives if necessary. So I can push the new version into CI before fixing all the new things it found so that developers get the benefits of the upgrade tool right away. I use git blame -n pared with the cppcheck( or any tools )output. That way I have a list of things that I can filter out of a tools output.
from the git blame man page
-n, --show-number
Show the line number in the original commit (Default: off).
Last edit: john borland 2023-08-17
Oh I didn't think about git tracking line numbers. That's perfect. Thanks!