future of commitment to MinGW 3

[mabrand]

Sadly, I had to drop the MinGW targets from qtbase after realizing that it doesn't build. 4c530e2

I don't think MXE really wants to maintain forks of MinGW or Qt to keep them compatible. The Qt project no longer officially supports MinGW, having focused on MinGW-w64. In the past it's been possible to fix things up, but I question whether it's still worth the effort.

Anybody want to comment on this?

See #453 for more discussion of this.

[uwehermann]

We've recently switched to MinGW-w64 on the sigrok project as well, e.g. for some newer features in libserialport (commit) that needed newer USB-related DDK APIs that are not available in MinGW (thus we tried ugly hacks, that only partially worked, if at all).

I can only speak for sigrok, the reason we used MinGW instead of MinGW-w64 there was simply because it was the default and I didn't realize (or care) that there were other build targets initially (until the above issues appeared).

As far as I'm concerned there's no problem making MinGW-w64 the default and/or dropping MinGW completely (assuming that all packages that built with MinGW build with MinGW-w64 as well). The situation may be different for other projects though, dunno.

For the limited set of stuff we need right now (glib libzip libusb1 libftdi qt boost check) MinGW-w64 works just fine and since we want Qt5 (and more recent glib/glibmm as well), MinGW is a no-go for us either way.

[TimothyGu]

This is a very good question. My opinion on this would be keep MinGW until i686-w64-mingw32 supports all the packages MinGW supports.

Right now, i686-w64-mingw32 doesn't support the following packages i686-pc-mingw32 supports:

• hdf4
• libdnet
• libmicrohttpd
• libmikmod
• netcdf
• openscenegraph (see also Problems with OpenSceneGraph 3.0.x #11)
• plibc
• poco
• winpcap

The stats does not include the following:

• mingw-utils
• mingwrt
• pthreads-win32
• w32api

[tonytheodore]

Most of those were fairly straightforward to update, there's only dcmtk and hdf4 remaining. I'd suggest we switch over the default target sooner rather than later.

As to removing MinGW 3 completely, I'd initially thought we could leave it there for a release cycle or two with deprecation warnings. Now I'm leaning towards removing it before the next release, the longer it's somewhat supported, the harder it will be for people to change down the track, and the more work we'll have to do deciding what to disable or try to fix.

[TimothyGu]

@tonytheodore wrote:

Most of those were fairly straightforward to update, there's only dcmtk and hdf4 remaining.

Nice job! I have tried to update a few like winpcap and plibc, but without success. Have you tested building them?

I'd suggest we switch over the default target sooner rather than later.

+1. No problem on my end.

[tonytheodore]

@TimothyGu wrote:

Have you tested building them?

Only building, not running, but the downstream deps (libdnet libmicrohttpd) build okay also.

[TimothyGu]

@tonytheodore wrote:

Only building, not running, but the downstream deps (libdnet libmicrohttpd) build okay also.

Ok then.

[TimothyGu]

dcmtk ported.