Hi Chapel Developers (and perhaps particularly @diten) —
[Looking for comments on this in the next day or two, ideally].
In Chapel 1.26.0: building with GCC and CHPL_LLVM=bundled fails to find clang binary · Issue #19791 · chapel-lang/chapel · GitHub, a user ran into an issue where—due to the complexities of our Makefiles and host/target CC variables—we built a bundled LLVM but then couldn't find it again due to confusion about what compiler was used to build it. After wrestling with this a bit late last week, I came up with a proposed solution in Stop uniquifying LLVM's install directory by CHPL_HOST_COMPILER/CC by bradcray · Pull Request #19939 · chapel-lang/chapel · GitHub. @mppf has reviewed and approved it, but I wanted to make sure others had the opportunity to know about it / weigh in on it before I merge it if desired.
Specifically, the problem relates to the fact that a bundled LLVM build introduces a new C compiler (clang) that is used as CC in some contexts, but stored in a path that can be based on the (host) value of CC. The result is that, in cases where we're calling our chplenv scripts recursively, we look for the bundled build of clang in the wrong directory because we mistakenly use it as the host compiler. The PR walks through this circularity in more detail.
The proposed fix is fairly simple: to remove CHPL_HOST_COMPILER from the install path for the bundled LLVM to break this circularity. This has the potential downside to confuse users who may want to host multiple bundled LLVMs built using different host compilers in a single source tree, but in the PR Michael argued that we're already susceptible to this today, such that this doesn't make it much worse (while fixing an existing problem). Arguably, we're betting that not many users will want/need that capability for the time being.
Thanks,
-Brad