Raise minimum requirement to VS2017 #2228
Conversation
|
According to #2226 (comment), seems it's necessary to make sure VS2015 is fulling supported by Capstone. |
|
@kabeor I can, but we cannot guarantee it will work since Rizin hasn't tested VS2015 for many years already. In that case, it's better to create the corresponding CI job in the capstone repository but use GitHub Actions instead of AppVeyor. It's also notable that builds for Windows XP could be created even with VS2022; see OpenSIMH CI for example https://github.com/open-simh/simh/blob/master/.github/workflows/cmake-builds.yml#L112 |
Thats not really VS2022, thats using the VS2017 build toolset for WinXP (v141_xp) with the MSBuild from VS2022 (at least from a brief inspection). That does mean a minimum toolset of VS2017 won't then remove WinXP support so long as the v141_xp toolset is available/installed (I was under the impression v140_xp that came with VS2015 was the last XP version when I added #2226 (comment) since I've never installed VS2017 on any of my systems). |
|
Ok, changing to vs2017 now seems to make sense. Merged now. Then this link should be added in msvc doc to give necessary guidance to specific users. Still, vs2015 should be tested and supported in the future. |
Since the auto-sync changes Capstone use C99, no Visual Studio below 2015 could compile it. On the other hand, it's 2024 already, and maintainers have no reason to support this ancient software (the latest Visual Studio is VS2022).
Users of the legacy platforms could either update or use older capstone, or make custom patches/forks. Given the lack of maintainers, supporting those strains limited resources even further.
Instead of VS2015 I used VS2017 just to be safe because in Rizin we check all commits with this version precisely: https://raw.githubusercontent.com/rizinorg/rizin/dev/.appveyor.yml
Closes #2226