Refactor cross compile assistance

[runesoerensen]

We currently support targeting x86_64-unknown-linux-musl and aarch64-unknown-linux-musl on macOS and Linux, but the cross compile assistance provided is inconsistent depending on the host's CPU architecture. This refactoring aims to improve that across all supported target_triple and host OS/architecture combinations by providing helpful assistance for supported scenarios.

• Fixed Cross-compilation assistance: Help text "cross-compile" references are misleading #728 by improving the help text to include accurate advice for the target_triple relative to the current host OS and architecture.
• Fixed Cross-compilation assistance: Env vars not set when targeting x86_64_unknown_linux_musl from Linux #726 by adding support for targeting x86_64-unknown-linux-musl from AARCH64 Linux.
• Improves maintainability by sharing CrossCompileAssistance::Configuration initialization with relevant environment variables (when appropriate) in one place (which will be useful if we want to set additional environment variables in the future, i.e. Cross-compilation assistance: Set the CXX_* and AR_* environment variables too #725).
• Fixes part of Cross-compilation assistance: Some architecture/target combinations use the GNU GCC binary instead of the MUSL one #724 by adding support for targeting aarch64-unknown-linux-musl from AARCH64 Linux. The gcc binary used when targeting the same architecture is now musl-gcc on both aarch64 and x86-64.
  • However, the binary used when the architectures don't match is still the *-gnu-gcc variant (as for instance aarch64-linux-musl-gcc is only available on aarch64 Linux (this requires further investigation, and a separate issue should be created for that)).
• Adds support for targeting aarch64-unknown-linux-musl from aarch64 macOS.
• Adds strict host architecture checks to ensure that CrossCompileAssistance::Configuration or CrossCompileAssistance::HelpText is only returned when supported. Otherwise CrossCompileAssistance::NoAssistance is returned.

It also:

• Drops support for a gcc binary (x86_64-linux-musl-gcc) installed by a previously recommended macOS toolchain. Since the current toolchain has been recommended for nearly 2 years it's probably safe to assume (or fair to require) that users have update to the recommended toolchain.
  The brew formula/revision has also been bumped, so the missing dependencies mentioned here Update cross-compile assistance for Apple silicon #312 (comment) are now included

[Malax]

Thanks for the PR! 🎉

I gave this a skim-read to provide some early feedback since this is one of your first PRs around here. I understand that this is a draft still.

Apart from the mostly minor code comments, I was missing some context due to the fact there is not PR description and the title being very vague (what does it fix, is there an existing issue somewhere?) Again, this is a draft PR and I write my descriptions at the very end as well. If that was to come later - ignore my comment! :)

There also seem to be some slight different in packages recommended. Have you verified those on the respective systems? For example, libc6-dev-arm64-cross is no longer mentioned. It's possible it is not needed, but from the information I have it could also be an oversight. :)

[runesoerensen]

Apart from the mostly minor code comments, I was missing some context due to the fact there is not PR description and the title being very vague (what does it fix, is there an existing issue somewhere?) Again, this is a draft PR and I write my descriptions at the very end as well. If that was to come later - ignore my comment! :)

I have added a more elaborate description now with links to relevant issues. Merging this pull request should close those issues, but let me know if it's better to unlink them and manually close the issues with reference to this pull request!

Should I perhaps add a CHANGELOG entry as well?

There also seem to be some slight different in packages recommended. Have you verified those on the respective systems? For example, libc6-dev-arm64-cross is no longer mentioned. It's possible it is not needed, but from the information I have it could also be an oversight. :)

I initially removed the libc6-dev-arm64-cross package from the help text since, during testing, it was installed along with g++-aarch64-linux-gnu - but only as a recommended package - c5a046b adds it back in and explains why. The following commit adds the equivalent packages for amd64 cross compilation from aarch64 Linux

I'm not sure if musl-tools is still necessary, but also added that to both help texts. I will test further, but overall it's probably best to keep the changes introduced by this pull request minimal (and improve on the help text in another PR).

[Malax]

Thanks for the changes! Looking great! 👍🏻 Let's add a brief CHANGELOG entry and ship it!

[edmorley]

Thank you for this! The implementation is both cleaner and more correct now :-)

I tested this manually locally on macOS by packaging the Python CNB (which includes C deps, such as ring to exercise the env vars being set), in the following scenarios:

• the default target (x86_64-unknown-linux-musl) with and without the correct toolchain installed
• --target aarch64-unknown-linux-musl with and without the correct toolchain installed

...and it worked great for all of those.

(Longer term we have #730 and #731 for exploring trying to test more scenarios in CI)

However, the binary used when the architectures don't match is still the *-gnu-gcc variant (as for instance aarch64-linux-musl-gcc is only available on aarch64 Linux (this requires further investigation, and a separate issue should be created for that)).

The intention of #724 was to be about the general case of "we probably shouldn't be using the non-MUSL gcc ever". This PR helps with a subset of cases, but not all (as you mentioned in the PR description). Rather than close #724 out, I've morphed the title to make it clearer that it's about the general case :-)