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

[Gregorio Litenstein]

Hey there! yeah, I definitely like this idea and I agree it would be tidy and flexible.

I personally wouldn't want to see the plug-in mechanism gone completely as I use it for performous but then again I could probably find some other solution if it were to be done away with.

Now I wonder... Which percentage of packages don't build because a newer gcc and which percentage don't because because of a newer gcc AND the fact they're ancient? What I mean is... I'm fairly sure at least some of the FTBFS would probably be fixed by updating the packages themselves to newer versions. Take the case of icu4c (for which I also made a PR btw); mxe currently ships 56.1, which was released in 2015.

On Aug 30, 2019, 06:47 -0400, Tony Theodore <address@hidden>, wrote:

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