-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avoid cppcheck version 1.88 due to performance issues #168
Conversation
Signed-off-by: William Woodall <william@osrfoundation.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tried running this but it looks reasonable to me as a workaround.
One thing to consider is that 1.89 is "due" in 5 weeks according to their trac instance: https://trac.cppcheck.net/milestone/1.89 I don't know if they'll consider doing a 1.88.1 or something similar and I don't know how long after that it will be picked up by homebrew and choco, so we might be looking at a gap of months. |
Either way, this patch will prevent the test from misbehaving so I think we should take it. Perhaps we can manually install an older version (e.g. 1.87) on the CI machines, then it would only affect end users who don't choose to downgrade themselves. |
By emitting a warning this patch causes a bunch of CMake warnings in CI. I'm not sure if there's whether it's better to relax the warning to just a message, have it warn but squelch it during CI runs, or another workaround but it doesn't seem useful to live with the warnings in CI, though I'm willing to be swayed by a compelling argument for doing so. |
My suggestion (but I forgot to include it) was going to be to add it to the filter in CI, that way it would remain highly visible for end users, but I can also downgrade it to a status message if you guys prefer. |
I would not like to live with the warnings persisting on CI. |
For the sake of keeping it simple I would downgrade the message to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see anything showstopping so this can merge as long as we have a satisfactory CI build.
I do have a question about the interplay between skipping the test via CMake checking the version and the runtime check: I haven't dug into the CMake logic but my expectation from reading the patch is that if cppcheck 1.88 is found during CMake build, tests using ament_cmake_cppcheck will be skipped unconditionally, so there's no way to force the use of cppcheck 1.88. Is that correct? On the other hand, the runtime check in ament_cppcheck is override-able via environment variable? --again assuming that I'm reading the patch correctly. |
Also, I think this will need a backport (via fast-forward or otherwise) into Dashing in order to allow CI builds against the Dashing release to be run without this problem. |
Actually, I thought of something. If the performance impact noted here: ros2/build_farmer#220 (comment) on cppcheck master is present in a future release is there any possibility that we would extend the test skip even though the impact was not fatal? If so, should we consider disabling versions >= 1.88 and then updating the patch when a satisfactory release is made? Edit: I mostly raise this concern because I think we'll need to backport this to Dashing in order to enable CI builds against the release state once all Mac and Windows hosts have the upgraded cppcheck. |
That's correct. I didn't think it necessary, but I could add a cmake option if you guys want.
That's also correct, but my thinking was that if we were testing it we might want to override the CLI, but that there was little value in overriding it via cmake, but that was just a arbitrary decision on my part, I'm happy to change it if desired. |
I've already tested master and it's a lot faster and has all the patches that @cottsay pointed out, so I hope the next version will be fixed. I can update it to trigger on >= 1.88 if you guys want. I'll open a pr for backport into dashing. We could ignore the failure, but it adds time to the CI since it has to repeatedly try it 10 times, timing out each time after 120s. |
Thanks for the clarifications. I am good with everything as-is. If we're sanguine about the next cppcheck release I am okay with skipping just on ==1.88. |
All the test failures were know ones, so I'm merging this and I'll open the backport. |
* avoid cppcheck version 1.88 due to performance issues Signed-off-by: William Woodall <william@osrfoundation.org> * downgrade to status from warning when skipping
I'm opening this as a possible solution to the cppcheck 1.88 issues we've been seeing, see: ros2/build_farmer#220 (comment)
This isn't ideal as our build machines will not be checking cppcheck during this period until a new fixed version of cppcheck is available (master already has fixes), and the same will be true for our users who may install cppcheck, but won't get checking until 1.88+.
However, it avoids the need for us to modify the installation instructions and instruct people to pin or install older versions of cppcheck only to remove those instructions again when 1.88+ is available (hopefully soon).
It modifies the CLI to print a message and return
188
, e.g.:As the message implies if you set a specific environment variable you can override that:
Which currently crashes on my computer for
rclcpp
.If you're using
ament_cmake_cppcheck
then you'll get a CMake warning:And the test will "pass":
But the test result will show it as skipped:
I'd like to hear from others if they think this is an appropriate workaround for now or not.