Add mingw basic support #2196
Add mingw basic support #2196
Conversation
Plugins/agsblend/AGSBlend.cpp
Outdated
| #define max(x,y) (((x) > (y)) ? (x) : (y)) | ||
| #endif | ||
| #define math_min(x,y) (((x) < (y)) ? (x) : (y)) | ||
| #define math_max(x,y) (((x) > (y)) ? (x) : (y)) |
There was a problem hiding this comment.
It's better to go opposite way and disable macros coming from windows.h. Not only having to rename macros annoying, but also windows.h macros will prevent using std::min/max if one wishes to switch to these.
First I'd double check why windows.h is included here, but likely it's because of allegro.h
Then there are two ways the window header may be dealt with:
- Undef-ing conflicting macros after the header.
- Defining
#define NOMINMAXbefore the header - in which case windows.h will skip these macro definition.
For example see
https://github.com/adventuregamestudio/ags/blob/master/Common/platform/windows/windows.h
There was a problem hiding this comment.
I noticed a few things were actually supposed to be built only in non-builtin plugins, so I adjusted that, but also used the NOMINMAX define there and used std::min and std::max instead.
Engine/util/library_windows.h
Outdated
| @@ -103,7 +104,11 @@ class WindowsLibrary final : public BaseLibrary | |||
| { | |||
| if (!_library) | |||
| return nullptr; | |||
| #if AGS_PLATFORM_WINDOWS_MINGW | |||
| return reinterpret_cast<void *>(GetProcAddress(_library, fn_name.GetCStr())); | |||
| #else | |||
There was a problem hiding this comment.
I think this does not need a platform switch, as this may be a valid type cast regardless.
MSVC seem to be tolerant to missing headers and type casts sometimes, so it does not error on these.
There was a problem hiding this comment.
I removed the check and used the reinterpret_cast as the way to go there.
ericoporto
force-pushed
the
add-mingw-basic-support
branch
from
e6f8997 to
e644cee
Compare
this cast is not required on MSVC.
`__except` is not supported on mingw and will require a different code for exception handling. I found working code but it used an undocumented nt api, so this is better to research with calm.
this is to avoid manually copying mingw dlls, and ensures a portable binary the same as traditional acwin.exe
This is to be able to build on Windows by using MinGW instead of MSVC. Of course, we will forever use MSVC because of the Editor (and C++/CLR), but still, wanted to investigate possibilities - just to safeguard.
Here is a 64-bit build through MinGW: ags.zip
Known issue: SDL2 is statically linked and SDL2 statically linked has some issue with fullscreen on Windows I couldn't yet figure it out (this happens in MSVC too, so it's not mingw specific)
There is no rush here, so this can be reviewed with calm.