On 08.12.2025 16:19, Luca Fancellu wrote:
>>>> Now this is (to me at least) absurd: I'm removing a file, just to find the
>>>> pipeline
>>>> fails because cppcheck doesn't like docs/misra/exclude-list.json
>>>> containing a
>>>> reference to a non-existing file.
>>>>
>>>> I'll amend the commit with
>>>>
>>>> --- a/docs/misra/exclude-list.json
>>>> +++ b/docs/misra/exclude-list.json
>>>> @@ -170,10 +170,6 @@
>>>> "comment": "Imported from Linux, ignore for now"
>>>> },
>>>> {
>>>> - "rel_path": "common/symbols-dummy.c",
>>>> - "comment": "The resulting code is not included in the final
>>>> Xen binary, ignore for now"
>>>> - },
>>>> - {
>>>> "rel_path": "crypto/*",
>>>> "comment": "Origin is external and documented in
>>>> crypto/README.source"
>>>> },
>>>>
>>>> but I think such tidying should be optional.
>>>
>>> Can you share the error?
>>
>> + xen/scripts/xen-analysis.py --run-cppcheck --cppcheck-misra -- -j16
>> ERROR: Issue with reading file
>> /builds/xen-project/hardware/xen-staging/docs/misra/exclude-list.json:
>> Malformed path: common/symbols-dummy.c refers to
>> /builds/xen-project/hardware/xen-staging/xen/common/symbols-dummy.c that
>> does not exists
>
> Oh ok I see, seems to me a good feedback from the tool to keep everything
> consistent.
Well. If I remove a file from the xen/ subtree, then seeing empty grep output
on that
subtree should allow me to be sufficiently sure that no problematic (as in:
breaking
the build) references have survived.
Plus while I agree that consistency is desirable to have here, is a stale file
ref
really a reason to cause a build to fail? Wouldn't a warning suffice?
How many tools' behaviors can we (as developers, reviewers, and committers)
keep in
mind when putting together otherwise simple changes?
Jan
