Activate Experimental Platforms

[jeremiahpslewis]

There are currently 214 instances of platforms = supported_platforms() in the Yggdrasil code base, i.e. cases where (mainly because the script has yet to be updated), experimental platforms like Apple Silicon are not supported. A rough grep of build_tarballs(ARGS suggests this is ~25% (214 / 926) of binary files.

This migration is a very specific change which is repetitive and creates (what I assume to be) an added burden on maintainers.

Would it make sense to get a few people together on a couple of afternoons and do an 'experimental platforms hackathon' to move this number from 25% towards ~0%? This could be planned so that it is maximally convenient for maintainers and so that open PRs don't pollute the repo.

Thoughts? @giordano

[giordano]

Duplicate of #2763

[giordano]

To be clear, as explained in that issue, there are strong constraints related to the change, it isn't as easy as doing a mass sed substitution, otherwise we'd have done that long ago. We have anyway to move on a case-by-case basis, as we're already doing it now.

Besides, it's a somewhat "breaking" change (dropping support for older versions of Julia), maintainers of the Julia packages using the jlls may not be happy about that. We have had a few maintainers that specifically didn't want to move to 1.6 only because they wanted to support previous versions of Julia for new versions of the package, so there is also that to keep in mind.

In addition, I was already planning to make experimental=true the default in BinaryBuilderBase.jl a few weeks after v1.6 becomes the new LTS, but we aren't there yet

[jeremiahpslewis]

Ok, thanks. Then I'll keep on sending over PRs as I find dependencies in my stack that can be updated, but won't push anything more systemic. :)

1. Definitely not suggesting a find / replace, rather getting a small set of ppl to go and check for new versions, update, test local and then submit PR.

2. Gotcha, glad that the 1.6 requirement isn't turning out to be a limiting factor.

3. Does this mean all binaries will be rerun & rebuilt once v1.6 hits LTS? Think one open problem here is that many libraries (in absolute numbers, not as pct) will not build and need to be manually debugged, given that (afaict) we don't continuously CI the binary scripts and the scripts (given external dependencies, subsequent updates to RootFs) don't ensure idempotence.