StephanTLavavej / mingw-distro

MinGW distro build scripts.
492 stars 55 forks source link

Upgradation #90

Closed Spidy104 closed 7 months ago

Spidy104 commented 2 years ago

When will the whole distro set be upgraded or has it been deprecated??

StephanTLavavej commented 2 years ago

I'll try to find some free time this summer.

fdiedler commented 1 year ago

Hi @StephanTLavavej

Will the distro be updated with the last gersion of GCC ? I use it for many years in my IA project and you have done a good job, many thanks ;)

Hope this distro will not be deprecated...

StephanTLavavej commented 1 year ago

I'm still planning to update it, I just need to find a free weekend.

fdiedler commented 1 year ago

@StephanTLavavej Did you have time to upgrade your distro ? Thanks

oscarbg commented 1 year ago

+1

fdiedler commented 1 year ago

@StephanTLavavej Hi, will you upgrade or not your distro ? I use it in my IA project and your distro is really good :) Thanks

StephanTLavavej commented 1 year ago

I do intend to upgrade it, hopefully this year, but I have been extremely busy and the distro is near the bottom of my priority list. Sorry.

wehostadm commented 9 months ago

@StephanTLavavej I am also looking for an upgradation for this wonderful package :) Hope you will have time to upgrade it with the last stable versions of GCC/G++ and libraries Thanks

AndrewSav commented 7 months ago

It would be nice if this could be kept up to date, gcc 12 is what we need ;)

StephanTLavavej commented 7 months ago

I might try to build an updated distro soon (no promises).

AndrewSav commented 7 months ago

@StephanTLavavej I had a look at helping, but this repo has patches with no explanation why they are needed, so it's hard to judge if they should be carried over (and why).

For boost 1.84 you will probably need this patch: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-boost/0012-allow-longer-path-on-mingw-w64.patch Without it libboost_url compiling fails because ar tries to use a response file, due to long command line, and backslashes in the response file come out wrong way so the compilation fails. Just to save you a wee bit of time.

StephanTLavavej commented 7 months ago

@AndrewSav Thank you!! I started working on the distro build and encountered that exact issue with Boost.URL. This will really help!

Some of the patches in the repo (glbinding, binutils) are from PRs that were merged and are no longer necessary after upgrading. Other patches are hacks I've developed over time to just get the stuff building (most notably coreutils, which I will be attempting to completely replace this cycle). My elusive goal is to get the distro to build patch-free. I could indeed have done a better job adding comments. In general, "see what happens without the patch" will give some idea of what it's doing.

AndrewSav commented 7 months ago

In general, "see what happens without the patch" will give some idea of what it's doing.

I was not so sure about that when looked at the big mpfr patch. I thought it might be not because it would not compile, just because you were hitting an issue with some software you built using that library, so you patched it.

StephanTLavavej commented 7 months ago

Oh, that was an "official" patch from the website - they sometimes include it on their webpage instead of making proper point releases. The current version doesn't appear to have such a patch, so I'm dropping it.

StephanTLavavej commented 7 months ago

Status update: I spent the last part of my winter vacation working on this, and I've updated all components with only 7-Zip (easy) and coreutils remaining. For coreutils I want to try a complete replacement. No ETA yet but I'll try to return to this next weekend as I'm close.

AndrewSav commented 7 months ago

I would be interested in submitting a PR to make this run on GitHub actions when you are done, to make the next upgrade somewhat easier. Same as you - no commitments, though. Would you be interested?

StephanTLavavej commented 7 months ago

I'm not sure how that could save time, and it sounds like it would take work to maintain. I'd say I'm not very interested although I wouldn't reject the idea immediately.

The primary time sink is having to figure out what breaks whenever a new version of a component is released. Sometimes it's trivial, sometimes it takes a while to investigate.

What would help me is getting issues fixed upstream; I've been trying to get better at filing tracking issues in this repo, I just don't have the time to go deal with upstream repos.

AndrewSav commented 7 months ago

Fair enough. I agree that 'the primary time sink is having to figure out what breaks whenever a new version of a component is released', for you, but if another person (like me) wants to contribute, they will spend time on scouting where each tar comes from downloading them and and putting them into the right place for the script to pick up. It does not make it easy to help. With the action, you could just update the versions and run the build see where it fails and go from there (what you mentioned). You could run the script locally as well. Also saves some time on bundling...

But if you do not see value in this, fine by me.

What would help me is getting issues fixed upstream

Yeah, I personally have quite a dim view on the success chance here, and not ready to take on what I view as almost hopeless enterprise.

StephanTLavavej commented 7 months ago

Distro 19.0 is now available - enjoy!