Skip to content
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

fix #12753: --library looks for extension-less file in CWD only #7207

Closed
wants to merge 2 commits into from

Conversation

ludviggunne
Copy link
Contributor

No description provided.

@firewave
Copy link
Collaborator

I am not sure this should be added at all. I filed the ticket to document the current differences. I would rather have it removed because (IIRC) none of the other configurations support this.

I did not act on this yet because I am still in the midst of cleaning up the configuration loading which will in the end result in a single logic shared by all of them. I was hoping it would be completed in the short-term but totally separate logic in the GUI and test code made this way more complicated then it has to be. And then I got sidetracked again ...

@firewave
Copy link
Collaborator

firewave commented Jan 11, 2025

On a side note - strangely the ticket is "assigned" but has no user set and there are no traces that has been changed in the history. So it looks like I wanted to assign myself when creating it but forgot to fill the username.

@ludviggunne
Copy link
Contributor Author

I am not sure this should be added at all. I filed the ticket to document the current differences. I would rather have it removed because (IIRC) none of the other configurations support this.

Ok. I did think it was a bit strange to look for files without extensions, although I suppose it's good to have the option to omit the extension on the command line.

I did not act on this yet because I am still in the midst of cleaning up the configuration loading which will in the end result in a single logic shared by all of them. I was hoping it would be completed in the short-term but totally separate logic in the GUI and test code made this way more complicated then it has to be. And then I got sidetracked again ...

I suppose I should just leave this to you then? Or at least wait for your changes.

@firewave
Copy link
Collaborator

Ok. I did think it was a bit strange to look for files without extensions, although I suppose it's good to have the option to omit the extension on the command line.

The problem is that we have various external files like libraries, platforms, addons, etc. (follow --debug-lookup). Having all those without any extensions sitting in a single path seems a bit messy. So I think they should at least have an extension (which are not even unique). I would even go further and say that we should not look directly next to the executable but always in the folder structure (which would also make the lookup code much easier).

I suppose I should just leave this to you then?

It would be great to have some help. There is just too much to do.

Or at least wait for your changes.

That would probably be a while. There are more pressing things at the top of my list.

It seems the next step is not that complex. That would be to align the behavior (not the code yet) between CLI and GUI loading - see https://trac.cppcheck.net/ticket/12752#comment:6. After that make the loading logic generic in a helper and use it for CLI and GUI code. After that look at the other lookups and use the generic code there as well. And then we have probably some tickets which can be closed as fixed or worksforme.

The main problem here is making the decision on what the intended lookups are because either are taking liberties (and the rest of the bunch might as well). That's I would align the behavior first before making the code shared.

@ludviggunne
Copy link
Contributor Author

I see. I've been directed towards pure bug fixes so unfortunately I won't look in to that in the near future. I'll close this for now.

@firewave
Copy link
Collaborator

I understand.

I am afraid there might not be that many low-hanging fruits outside the actual checking code - even if they appear to be. Because I do not know how to write checks I focus on such and easy stuff usually results in fast fixes - and then it is not easy at all and suddenly you have dozens of open PRs to your name...

I usually try to provide all information in the tickets. But sometimes I just file them so the task does not get lost and they might be too barebones.

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