Skip to content

document external file lookup order [skip ci] #7613

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

firewave
Copy link
Collaborator

No description provided.

@firewave
Copy link
Collaborator Author

The current behavior of the lookup of external files is wildly inconsistent for each type and depends on if you are using the GUI or CLI. This can be mostly observed in test/cli/lookup_test.py (CLI) and https://trac.cppcheck.net/ticket/12752 (GUI).

This is a PR to determine the intended(!) order of the lookup of external files with goal of having a defined and shared implementation. The current change of the manual contains what I consider the most sensible order. Obviously open to any discussion/feedback on this.

I also considered making some of these lookups configurable to avoid some potentially unwanted behavior:
https://trac.cppcheck.net/ticket/12810
https://trac.cppcheck.net/ticket/13505

There's also other related tickets:
https://trac.cppcheck.net/ticket/10774
https://trac.cppcheck.net/ticket/13880

I did not include a list of the known issues as those are mostly evident by above references and should not affect the discussion and are simply the steps to ensure we arrive at the intended behavior.

CC @danmar @ludviggunne @andresailer @ledocc @nlebedenco @c72578

@firewave
Copy link
Collaborator Author

firewave commented Jul 8, 2025

A case against supporting CWD in the lookup (from #7639 (comment)):

"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."

@danmar
Copy link
Owner

danmar commented Jul 8, 2025

A case against supporting CWD in the lookup (from #7639 (comment)):

Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.

@danmar
Copy link
Owner

danmar commented Jul 8, 2025

"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."

I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..

@firewave
Copy link
Collaborator Author

firewave commented Jul 9, 2025

Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.

It looks relative to the project file. Looking relative to the CWD is a different lookup. That should be evident in the expected output of test/cli/lookup_test.py

I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..

It will probably be installed in some common location. If files are distributed with it they would be placed relative to that so it will use the lookup relative to the executable location.

But you just gave the use case for CWD. If you have a custom script which invokes it you might place addition or overrides next to the script. The question though if CWD should override the project file - I think not, because the more specialized location should always override the more common ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants