danmar
deprecated platform types `win32A` and `win32W` in favor of `win32a` and `win32w`
This allows us to simply load the given library from the filesystem instead of converting it. See #4325 for the PR to get rid of the hard-coded platform data.
As far as I understand an alternative is to name the platform file "win32A.xml" and "win32W.xml" instead.
I do not know if users prefer win32A or win32a.
All the external files have been lowercase so far and I would like to keep that. Otherwise it would open the door for allowing mixed casing and that would lead to different behavior based on the filesystem.
And if we just use lowercase files and convert all the input strings that would allow any casing to be found which also isn't nice.
These might also be referenced in other configurations where I am currently not sure how that is even used (seems we are lacking test coverage there).
We should have it consistent and simple. That would also require less tests to be written to assure it actually works in all cases.
If we internally say win32A or win32a I don't care at all. I don't feel sure it's necessary to break the user interface. I mean this does not cause any users problems today as far as I know. And for us, I don't see that there is a big issue.
We could have a hardcoding in our code so "win32A" means "win32a" and "win32W" means "win32w". That is 2 strings to handle. Not very much. Then it will be backwards compatible.
.. do we really break the users scripts/plugins etc for very good reasons?
If we internally say win32A or win32a I don't care at all. I don't feel sure it's necessary to break the user interface. I mean this does not cause any users problems today as far as I know. And for us, I don't see that there is a big issue.
We could have a hardcoding in our code so "win32A" means "win32a" and "win32W" means "win32w". That is 2 strings to handle. Not very much. Then it will be backwards compatible.
.. do we really break the users scripts/plugins etc for very good reasons?
I want to get rid of special handling even if it just a line or two. Those things add up and they all need tests and handled in possible multiple cases.
The goal here is get rid of hard-coded stuff and make it all generic. I have several follow-up PRs on this which I will post soon. Maybe it makes more sense if you see where I want to head.
Here is our list of "client and plugins" from our webpage:
Buildbot - integrated CLion - Cppcheck plugin Code::Blocks - integrated CodeDX (software assurance tool) - integrated CodeLite - integrated CppDepend 5 - integrated Eclipse - Cppcheclipse gedit - gedit plugin github - Codacy and SoftaCheck Hudson - Cppcheck Plugin Jenkins - Cppcheck Plugin KDevelop - integrated since v5.1 Mercurial (Linux) - pre-commit hook - Check for new errors on commit (requires interactive terminal) QtCreator - Qt Project Tool (qpt) Tortoise SVN - Adding a pre-commit hook script Visual Studio - Visual Studio plugin
So what is our plan to update these..
I get the argument but we probably have broken things even worse recently.
I adjusted the code so it now states that it will be removed in an unspecified future version. So things will at least get cleaned up in some cases - mostly in out own usage.