You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?"
The text was updated successfully, but these errors were encountered:
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.
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).
Up until recently, if we were building a version of Chapel with llvm enabled, we would build the runtime twice:
clang
--no-llvm
In PR #17800, we unified the
--llvm
flag intoCHPL_TARGET_COMPILER
such that when Chapel is built with LLVM enabled,CHPL_TARGET_COMPILER
defaults tollvm
when unset andclang
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 tognu
,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 simplemake
command, it will not rebuild the compiler, but just the runtime. Alternatively, users can learn to typemake 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
yetCHPL_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 tollvm
(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 orCHPL_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?"
The text was updated successfully, but these errors were encountered: