future of commitment to MinGW 3 #492

Closed
mabrand opened this Issue Aug 28, 2014 · 10 comments

Comments

Projects
None yet
4 participants
@mabrand
Member

mabrand commented Aug 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@uwehermann

uwehermann Aug 28, 2014

Contributor

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.

Contributor

uwehermann commented Aug 28, 2014

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 comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Sep 4, 2014

Member

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 #11)
  • plibc
  • poco
  • winpcap

The stats does not include the following:

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

TimothyGu commented Sep 4, 2014

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 #11)
  • plibc
  • poco
  • winpcap

The stats does not include the following:

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

TimothyGu added a commit that referenced this issue Sep 16, 2014

libmikmod: update and support mingw-w64
See #492.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>
@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Oct 3, 2014

Member

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.

Member

tonytheodore commented Oct 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 3, 2014

Member

@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.

Member

TimothyGu commented Oct 3, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Oct 3, 2014

Member

@TimothyGu wrote:

Have you tested building them?

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

Member

tonytheodore commented Oct 3, 2014

@TimothyGu wrote:

Have you tested building them?

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

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 3, 2014

Member

@tonytheodore wrote:

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

Ok then.

Member

TimothyGu commented Oct 3, 2014

@tonytheodore wrote:

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

Ok then.

TimothyGu added a commit that referenced this issue Oct 8, 2014

dcmtk: Enable on i686-w64-mingw32
See #492.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>
@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 8, 2014

Member

dcmtk ported.

Member

TimothyGu commented Oct 8, 2014

dcmtk ported.

@tonytheodore

This comment has been minimized.

Show comment
Hide comment
@tonytheodore

tonytheodore Oct 9, 2014

Member

dcmtk ported.

Nice! I'm happy to leave hdf4 in a disabled state till either the project updates to mingw-w64 or users request support. It's a legacy format and there are tools to migrate to hdf5 - library support isn't that critical.

I think complete removal of MinGW v3 is the way to go, the question is how we handle existing build scripts and other blog/StackOverflow references to i686-pc-mingw32. Alias, warn, or fail?

Member

tonytheodore commented Oct 9, 2014

dcmtk ported.

Nice! I'm happy to leave hdf4 in a disabled state till either the project updates to mingw-w64 or users request support. It's a legacy format and there are tools to migrate to hdf5 - library support isn't that critical.

I think complete removal of MinGW v3 is the way to go, the question is how we handle existing build scripts and other blog/StackOverflow references to i686-pc-mingw32. Alias, warn, or fail?

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 9, 2014

Member

@tonytheodore said:

I'm happy to leave hdf4 in a disabled state till either the project updates to mingw-w64 or users request support. It's a legacy format and there are tools to migrate to hdf5 - library support isn't that critical.

+1. I'll take a stab at it probably in a week.

I think complete removal of MinGW v3 is the way to go, the question is how we handle existing build scripts and other blog/StackOverflow references to i686-pc-mingw32. Alias, warn, or fail?

I'd rather go with aliasing and warning, like the current .static warning. These warnings should be changed to errors after the release.

Member

TimothyGu commented Oct 9, 2014

@tonytheodore said:

I'm happy to leave hdf4 in a disabled state till either the project updates to mingw-w64 or users request support. It's a legacy format and there are tools to migrate to hdf5 - library support isn't that critical.

+1. I'll take a stab at it probably in a week.

I think complete removal of MinGW v3 is the way to go, the question is how we handle existing build scripts and other blog/StackOverflow references to i686-pc-mingw32. Alias, warn, or fail?

I'd rather go with aliasing and warning, like the current .static warning. These warnings should be changed to errors after the release.

TimothyGu added a commit to TimothyGu/mxe that referenced this issue Oct 14, 2014

Remove i686-pc-mingw32
Fixes #400 and #492.

See #453.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>

TimothyGu added a commit that referenced this issue Oct 14, 2014

hdf4: Enable on i686-w64-mingw32
This was the last package only supported by MinGW 32.

Yay!

See #492.

Signed-off-by: Timothy Gu <timothygu99@gmail.com>

@TimothyGu TimothyGu closed this Oct 14, 2014

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Oct 14, 2014

Member

hdf4 ported. i686-pc-mingw32 removed. Bug fixed.

Member

TimothyGu commented Oct 14, 2014

hdf4 ported. i686-pc-mingw32 removed. Bug fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment