R and its dependents: move to gcc13 and clang16/17

[barracuda156]

It is desirable to update compilers being used at once, since such change entails revbumping 4k ports :) It is desirable to use to latest GCC, since Macports use that to build earlier ones (so remaining on gcc12 implies that one has to build gcc13 and then gcc12, which on older machines takes forever).

I will test gcc13 from my side; could someone test a newer clang?

[jmroot (Joshua Root)]

I understand that the R port and portgroup need to stay in sync with the compiler they choose, but why do all the dependents need to be rev bumped? They will be built with a different compiler in future, but that's the case for all ports whenever we change the compiler fallback list, or indeed whenever users install a new Xcode version.

[barracuda156]

Replying to jmroot:

I understand that the R port and portgroup need to stay in sync with the compiler they choose, but why do all the dependents need to be rev bumped? They will be built with a different compiler in future, but that's the case for all ports whenever we change the compiler fallback list, or indeed whenever users install a new Xcode version.

R upstream insists that identical compiler should be used for R itself and all R packages. I have no idea to what extent there is substance to the claim, but if we do not follow this, it is pretty likely no tickets will be accepted by R-related upstreams (besides, obviously, a possibility that something works incorrectly, models spit out wrong results etc.).

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

R upstream insists that identical compiler should be used for R itself and all R packages.

Perl insists on that too. We decline to follow it there as it's unrealistic, and I suggest you decline to do that for R and elsewhere in MacPorts too.

[barracuda156]

Replying to ryandesign:

Replying to barracuda156:

R upstream insists that identical compiler should be used for R itself and all R packages.

Perl insists on that too. We decline to follow it there as it's unrealistic, and I suggest you decline to do that for R and elsewhere in MacPorts too.

OK, let us try that. I am fine with it.

[barracuda156]

FWIW, gcc13 builds fine for PowerPC. Still need to test using it.

[barracuda156]

Replying to ryandesign:

BTW how do we technically do this? I mean, CI gonna fail on time out for sure.

[catap (Kirill A. Korinsky)]

Sergey, is it possible to move R to noarch dependencies like I did for lisp ports? At least it allows to avoid massive revbump each time when one of lisp is released a new version.

[barracuda156]

Replying to catap:

Sergey, is it possible to move R to noarch dependencies like I did for lisp ports? At least it allows to avoid massive revbump each time when one of lisp is released a new version.

We decided not to revbump R packages anyway.

But I do not get what you mean by noarch deps here. Those packages which only have R code are already noarch. But many use C/C++/Fortran.

[catap (Kirill A. Korinsky)]

Replying to barracuda156:

But I do not get what you mean by noarch deps here. Those packages which only have R code are already noarch. But many use C/C++/Fortran.

Some lisp packages also contains C-code. Anyway, usually lisp machine compiles everything on demand.

Some packages like maxima and a few more distirbuted as precompiled binary output which leads to the same issue: it should be revbump when used lisp machine is upgraded.

But all cl-* ports are installed only sources, and it is compiled under user's cache.

[ryandesign (Ryan Carsten Schmidt)]

[61478943fcc56fd672a6f2139abb4f7ea0254903/macports-ports] resolves this ticket, doesn't it?

[barracuda156]

Replying to ryandesign:

[61478943fcc56fd672a6f2139abb4f7ea0254903/macports-ports] resolves this ticket, doesn't it?

Yes, right. Sorry, I should have closed it from the PR.