using the bazel cc toolchain

[johnynek]

Thanks for taking up this repo!

I didn't see it in the readme, but have you looked at leveraging the cc_toolchain to set up a path for native-image so that it uses the same toolchain as the rest of bazel?

That's one issue we never tackled with the old code, actually the native images are not hermetic. This occasionally causes us some issues where we get cache hits, but since the glibc is different on the machine, the native-image doesn't actually run. I assume this is something that could be fixed if we made native-image hermetic and added tests for that.

Would be really lovely to have totally hermetic native-images from JVM code in a bazel repo.

[sgammon]

@johnynek you beat me to it! just commented on the previous andyscott/rules_graal#8

I've laid some of the development groundwork to approach this but haven't actually done it yet. Toolchains have drifted a bit and I need to re-learn some APIs.

OTOH, toolchain types have already landed for GVM and native-image themselves, which should let me resolve a GraalVM-specific javac and native-image even if the current toolchain isn't GVM.

Next up, I plan to use the --native-compiler-* flags in the native-image binary to pass in a toolchain-provided C compiler and expose the ability to pass custom cflags. Uber's hermetic cc toolchain is installed so I can test against Zig eventually.

What do you think? Is this a solid approach in your view?

[sgammon]

@johnynek done and i've invited you to be a collaborator :) there is a discussion where feedback can be shared after testing, and these rules now support a full drop-in replacement for rules_graal (no need to switch rules, just a load change from @rules_graal to @rules_graalvm).

relates to andyscott/rules_graal#10