Express cross-platform-ness of beam files

[pjk25]

in erlang_bytecode2 rule

[pjk25]

Like there is for rules_docker, there should probably be a flag to disable these transitions (--@io_bazel_rules_docker//transitions:enable=false).

[pjk25]

Like there is for rules_docker, there should probably be a flag to disable these transitions (--@io_bazel_rules_docker//transitions:enable=false).

Done

[pjk25]

It has occurred to me that it's possible we want to also represent the beam version with this transition, to be able to for instance target an otp 26 runtime, but compile with 25. I think this should be possible, if we indicate the otp version in the host or exec platform definition as well. The transition will then have to handle this compatibility, and also the @erlang_config repository will have to define cpu's for each beam version instead of the single beam cpu that this PR currently contains.

[pjk25]

It has occurred to me that it's possible we want to also represent the beam version with this transition, to be able to for instance target an otp 26 runtime, but compile with 25. I think this should be possible, if we indicate the otp version in the host or exec platform definition as well. The transition will then have to handle this compatibility, and also the @erlang_config repository will have to define cpu's for each beam version instead of the single beam cpu that this PR currently contains.

Thinking further about this, I'm inclined not to force/resolve the compatibility in the analysis phase of the build. This is partly because I can't think of how to achieve it without projecting out rules for each erlang version an annotating with exec_compatible_with & target_compatible_with and letting platform flags filter, and I see this being problematic when you just want to run with the host erlang, and see what happens. If we did just try to handle it with transitions, then I think we would need additional custom build settings to indicate what erlang jump is intended. Neither of these sound very good to me and so long as this PR is compatible with using host_platform/platform to set 2 erlang versions and test for example otp 25 bytecode running on otp 26, then this is sufficient with beam as a custom cpu that does not encode it's otp version.