Allowing compilation on msys2 #17369
Conversation
## Description Before there was no clear way of running msys2, and even if there was, there is no guarantee of it working, well I fixed it, and added a CI, so that we can always know if it works. Furthermore I added 2 targets more: UCRT64 and CLANG64, yes, compilation with clang64 means we can also compile with clang for windows on arm :D, plus clang has better error messages overall, anyway. ## Related Issues libretro#17367 ## Reviewers Anyone, it's my first PR here.
|
|
|
This is cool. Seems like EDIT: Nevermind, guess you already mentioned that in the related issue. But the docs should probably be updated to suggest that UCRT64 or CLANG64 as the default MSYS2 environment: https://docs.libretro.com/development/retroarch/compilation/windows/ |
|
Should I update the docs? |
|
I think it makes sense. But I just started working with RetroArch yesterday, and also wondering why it was not using UCRT64/CLANG64 instead of the MINGW64 environment. |
|
I don't want to be too prescriptive, I'll let the retroarch team handle this for now, then :) Maybe in another PR |
|
I think the documentation can at least mention that UCRT64 and CLANG64 environments can also be used. |
|
In general, RA builds are using the oldest feasible environment, to make sure the end result runs on as many devices as possible. For self-compilation, maybe better to use the default (and update the doc), but submitted code should still compile against mingw64 (as well as a number of other environments). If the platform is added as new (Windows ARM), then there is no history, so the default can be something currently reasonable. |
|
@zoltanvb , can still have mingw64 environment used by the buildbot or CI checks, right? |
|
Not sure if I understand the question, buildbot uses cross-compiler in a Docker container, the method will not be changed by this PR. However, the change may have negative impact for that. I believe d3d3207 was necessary to work around a problem that is still there. Is there any #ifdef you can use to exclude those 2 new targets, while keeping mingw64/32 related definition intact? |
As I explained, this has to be done as a CFLAG for those targets, those targets should specify for all files the windows version themselves, and not be hardcoded otherwise it won't be compilable on modern windows... However I think if they already use old mingw then mingw headers will themselves don't give a high value, so they will use by default old code. Now the problem is if you want to compile for old hardware on modern windows, in that case you would simply add CFLAGS the windows version you are targetting. I saw however CI didn't complain about this change. This shouldn't affect someone compiling from windows 7 (It has to be said that msys2 doesn't support win7 there anymore, sad beep) |
|
Tested it locally and the build seems fine so far, so we'll take the risk with this. Hopefully nightlies won't break in the process |
Description
Before there was no clear way of running msys2, and even if there was, there is no guarantee of it working, well I fixed it, and added a CI, so that we can always know if it works. Furthermore I added 2 targets more: UCRT64 and CLANG64, yes, compilation with clang64 means we can also compile with clang for windows on arm :D, plus clang has better error messages overall, anyway.
Related Issues
fixes #17367
Reviewers
Anyone, it's my first PR here.