Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#70340 closed defect (wontfix)

Could we do arch-specific revbumps of GCCs arch-specific?

Reported by: barracuda156 Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.9.3
Keywords: Cc: cjones051073 (Chris Jones)
Port: gcc14, gcc13, gcc12, gcc11

Description (last modified by ryandesign (Ryan Carsten Schmidt))

gcc ports were just revbumped across the board for a non-functional arm64-specific change in [df82c95db246abbf58ba09929118138ce14d357b/macports-ports]

The change itself is perhaps desirable (and must be also made for powerpc triples, which are still wrong), but it is very wasteful to force everyone rebuild gcc on all archs, when literally nothing has changed for those. (It is also wasteful for MacPorts infrastructure – buildbots could be doing instead something more useful.)

This also happened earlier on a few occasions. For someone with a slow hardware such revbump may translate into many hours or days of compilation, with strictly identical outcome as before.

What is the aim of doing it this way? It is really trivial to do it correctly, setting revisions per-arch when necessary. This is not needed for every port, of course, but for ports which may need several hours to build, it is justified.

I got a fast PowerMac, but even in this case I either need to stupidly waste 10 hours on rebuilds (when I just built all this some days ago) or revert revbumping locally (and it is unreasonable to expect every MacPorts end-user to be aware of overlay repos, check GitHub commits on every change to determine if it is justified, etc.).

Change History (5)

comment:1 Changed 4 months ago by cjones051073 (Chris Jones)

Personally, I chose not to complicate the port files by going down the road of having to deal with arch specific revisions...

Last edited 4 months ago by cjones051073 (Chris Jones) (previous) (diff)

comment:2 Changed 4 months ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

If it saves hours or days of compilation time it might be worth it.

comment:3 Changed 4 months ago by cjones051073 (Chris Jones)

Resolution: wontfix
Status: newclosed

OK if a similar situation rises again it can be considered. Nothing to do this time so will close this.

comment:4 in reply to:  1 Changed 4 months ago by barracuda156

Replying to cjones051073:

Personally, I chose not to complicate the port files by going down the road of having to deal with arch specific revisions...

I would be equally happy if there is just a separate revision for PowerPC, which is justified by a lack of buildbots, so here it does save hours or days of compilation. When one can simply download pre-built compiler, it is far less of a pain (and whether extra stress on buildbots is justified is not up to me to decide).

If arch-based revisioning is undesirable, we could think of some other way.

But to me it looks like sensible, not just in a context of recent revbump. Earlier there was a massive revbump of gcc ports due to some potential clang-related issue: obviously, that was also completely unnecessary for powerpc where clang is broken to begin with. On the other hand, I want to do some fix-ups for powerpc, and for those revbump is required – but only for powerpc, so why do it for everyone.

comment:5 Changed 4 months ago by cjones051073 (Chris Jones)

If you are suggesting *permanently* having arch specific revisions I am strongly against that. It is actual rare that updates are submitted that only affect a small number of platforms, so most of the time it is right to rev bump everything. I this case the fix to the triple for arm is one that could have only rev bump the revision for those platforms, but this would also be a temporary measure, removed on the next version update.

Note: See TracTickets for help on using tickets.