rvagg
commented
4 years ago @mmarchini that's correct, but we're going to need it at some point so you're welcome to hack such a feature in there. I'm just waiting for x86 or armv6 to be finally dead from something V8 or Node does and refuses to reverse and it stops them working here and I have to scramble to make a version selector work. There's also going to be cases where a recipe needs to switch based on version - like upgrading the version of gcc used.
So I could imagine two options for this - push the selection into the recipes themselves and let them choose whether to build or not or how to change based on the version. Or doing it above the recipes and letting them be run selectively based on the version according to some matrix (like VersionSelectorScript that we used for Node CI).
In both cases I think there still might be a problem with naming since recipe name is tied directly to distributable name. e.g. There might be a musl gcc6 and a musl gcc 8 for example. If they're separate recipes then they'd have different names but we'd want the distributable asset to have the same name. If they're forced into the same recipe then the recipe becomes very complicated because the Docker image needs both compilers installed and will need to switch between them - which decreases the utility of using Docker.
Anyway, have a poke at it. I could probably give you access to the server if it helps and if you're confident enough with how the pieces work that you don't think you'll introduce any chaos while tinkering.
I think this would be helpful to get input from the community on performance impact of pointer compressions so we can make an informed decision on https://github.com/nodejs/TSC/issues/790. This build should only be made available to v14, because until V8 8.0 pointer compressions are not considered a stable feature and have extra performance overhead as well as bugs.
From a quick look on the repo I don't think we have any way to limit which versions a recipe will include. Is that correct?