Re: [Mingw-cross-env-list] Default GCC version

[Tony Theodore]

Hi Gregorio,

> On 28 Aug 2019, at 21:27, Gregorio Litenstein <address@hidden> wrote:
> 
> About a month ago, I naively submitted a PR to update the gcc package to 
> 8.3.0; I was then told gcc8 actually existed and lived in plugins.
> 
> Something I’ve been asking myself since, though (and frankly also before, or 
> I wouldn’t have made the PR in the first place) is… does it actually serve 
> any purpose to keep a three-year old compiler as the default? Wouldn’t it 
> make more sense to update the default to 8.3.0 (or 9.2.0) and keep GCC5 as a 
> plug-in instead? There comes a point when keeping an old compiler just 
> becomes a drag because it makes updating other packages more difficult (it’s 
> already been happening for a while probably, I’d say)
> 
> Is there something I’m missing?

We’re missing a roadmap of planned development;) gcc version tracking
is a long-time issue trying to balance stability and new features.

Currently, gcc5 is the only version that builds all mxe packages, though
later versions build a very large subset. The plugin mechanism isn't
ideal for several reasons:
  - not immediately obvious for users
  - not easily visible in logs etc.
  - doesn't provide separation of gcc deps
  - hard to test new versions/fallback to old
  - doesn't provide package makefiles with awareness of compiler
  
I plan to make compiler selection part of the target spec i.e:
  x86_64-w64-mingw32.static.gcc8

This has many advantages:
  - users who want stability can just stay on a tested version
  - testing new versions is simple to enable and revert
  - complier deps are properly isolated
  - package makefiles can set appropriate compiler-based flags
  - makes it easier to introduce clang toolchain

In this scenario, mxe will no longer have a "default" compiler, just a
version that currently builds all packages. There'll be no pressure to
update that; we can keep it stable for (say) binary packages used in CI
environments, while giving users who want to build their own more
options. For that matter, we could build binaries for newer versions
to push the ecosystem along.

Keeping the current default at gcc5 gives us a strong forcing function
to deprecate the plugin mechanism.

I've had this working before (but lost all my WIP a few months ago), if
it's not ready again by December - we'll update the default.

Cheers,

Tony