-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
base: main
Are you sure you want to change the base?
Conversation
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 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: There's also other related tickets: 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 |
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." |
Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder. |
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 looks relative to the project file. Looking relative to the CWD is a different lookup. That should be evident in the expected output of
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. |
No description provided.