Hey everyone,
makes sense and from architectural point of view a clear solution.
x86_64-w64-mingw32.static.gcc8
Maybe there should be a default that is 'rock solid' for the already
known
x86_64-w64-mingw32.static
as a default for those who don't catch up in their build
environments.
Cheers,
Lars
Am 30.08.2019 um 13:52 schrieb 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
--
--------------------------------------
MBA B.Eng. Lars Holger Engelhard
eMail: address@hidden
mobil: 0049 176 23120355
web: http://www.lars-engelhard.com
|