It was mentioned that the correct way is to generate the proper project
structure for cppcheck using our existing tools that generate IDE
integrations (and they have correct include correct includes, deps and all).
Mike,
Yes, agreed. But AFAIK, no one other than me is looking into this. Quite a few issues with the
GbuildToIDE approach need to be solved.
In the meantime, our current cppcheck script generates tens of thousands of config errors (if run
with check-config or verbose),reports hundred or possibly thousands of false positives, and is
being called with depreciated parameters. These issues can be fixed now.
I am in the process of going through past cppcheck related commits to verify how many, if any at
all, would be missed had we been using the '-I include/' parameter. So far, I have not identified
any. If the consensus is that you do want to improve the script with the manual approach, I will
not continue testing. Please advise.
However, keep in mind that from the GbuildToJson output, any framework that is built in the future
will also call cppcheck with the '-I include/' parameter. Therefore, if there is a bug with
cppcheck not reporting valid errors when called this way, then that approach too will suffer too.
Context
- Cppcheck: Reduction of False Positives: Manual Approach (continued)
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.