Should we build the runtime twice when CHPL_LLVM!=none and CHPL_TARGET_COMPILER!=llvm?

[bradcray]

Up until recently, if we were building a version of Chapel with llvm enabled, we would build the runtime twice:

• Once for use with the LLVM back-end, compiled with clang
• Once for use with the C back-end, compiled with CHPL_TARGET_COMPILER for use with --no-llvm

In PR #17800, we unified the --llvm flag into CHPL_TARGET_COMPILER such that when Chapel is built with LLVM enabled, CHPL_TARGET_COMPILER defaults to llvm when unset and clang is used for building the runtime and third-party libraries.

One impact of this change is that, after such a build, if the user wants to switch between the C and LLVM back-ends, they will need to do a second build with CHPL_TARGET_COMPILER set to gnu, intel, or whatever their C back-end compiler is to get a copy of the runtime compatible with that compiler. If this second build is done with a simple make command, it will not rebuild the compiler, but just the runtime. Alternatively, users can learn to type make runtime. But in either case, it requires a second build by the user.

One situation that's a bit odd in the new world is to build with CHPL_LLVM!=none yet CHPL_TARGET_COMPILER!=llvm since this is saying "build an LLVM-enabled version of Chapel, yet use a C compiler as the back-end. This seems to work, but creates a dual of the previous paragraph in which the compiler can only be used with the C back-end, not the LLVM back-end, at least without doing a second build with CHPL_TARGET_COMPILER set to llvm (or unset).

This issue proposes that perhaps in this case, we should return to the practice of building the runtime twice, once with clang and once with the indicated target compiler. This would permit a user to do a single make command and to end up with a Chapel build that was capable of switching between C and LLVM back-ends using the --target-compiler flag or CHPL_TARGET_COMPILER environment variable.

This is arguably a bit subtle and only a minor convenience for those who learn and understand the invocation. But it also seems like an attractive convenience for those who do learn it, and also makes the configuration choice a bit more intuitive in the sense of "I enabled LLVM and indicated which C compiler I prefer; why can I not use both back-ends?"

[mppf]

I'm in favor of keeping the build-the-runtime-once strategy we currently have because I think it is simpler (both for users to understand and for us to implement). I think what we are facing here is both the challenge of making a change and the fact that it's not really documented anywhere how to do the runtime build for say PrgEnv-intel. In particular, if we don't change the make behavior as a result of this discussion we need to at least adjust the documentation.

[mppf]

Regarding the proposal specifically that CHPL_LLVM!=none and CHPL_TARGET_COMPILER!=llvm should cause the runtime to be built twice - this seems to me to be something that is not so intuitive that a user would think it obvious that it would build the runtime twice and by the time a user would look in the documentation to discover this option is available they might as well learn about how to run make twice or use make runtime, even. (It is especially new/strange to users to have to set CHPL_TARGET_COMPILER at all when using a PrgEnv but that is not changed by this proposal).