Re: compiling on 32-bit mingw

[Mojca M. <moj...@gm...>]

On 3 October 2016 at 10:37, Bastian Märkisch wrote:
> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
> and friends have been part of the API since Windows 2000 Pro according
> to MSDN. Mingw32 is currently also lacking support for several other
> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
> use in the near future. This is also not the only development
> environment with that problem: OpenWatcom's library is seriously out of
> date, too.
>
> To fix compilation with MinGW32 for now, we could add the old code back
> along with a number of #ifdef's, or extract the missing definitions from
> MSDN and add them to the our code (easily around 100 lines), or #ifdef
> out the affected code and functionality.
>
> Btw. Mingw64 and MSVC2015 compile gnuplot just fine.

This is not my area of expertise, but isn't MinGW-w64 a suitable
replacement for MinGW32?

I kind-of gave up on the original MinGW32, in particular in the area
of cross-compiling. MinGW-w64 seems much better supported and more
up-to-date (not to even mention the ability to create 64-bit
binaries).

It would be one thing to exclude everyone without MSVC. That would be
a bit sad. But I don't find it problematic to ask *developers* (the
few people who actually know how to compile under Windows and how to
get all the dependencies working) to switch to a different OpenSource
toolchain, in particular if supporting the "old" toolchain causes
additional headaches and more ugly code.

If gnuplot compiles fine under MinGW-w64, I don't see any reason to
use ugly workarounds in the code just for the sake of supporting an
alternative tool that lags behind.

Mojca