Chapel: "bundled" option for CHPL_ third-party environment variables?

[bradcray]

There are a number of Chapel environment variables relating to third-party packages that indicate whether to use the Chapel-provided version versus a system installation, like CHPL_GMP. Currently, the way we have these variables refer to the Chapel-provided version is using a setting like CHPL_GMP=gmp (CHPL_FOO=foo, in general). In a discussion on https://github.com/Cray/chapel-private/issues/1056, we kicked around the question of whether we should use a more symmetric/general term as the value for the Chapel-provided version, such as CHPL_GMP=bundled rather than CHPL_GMP=gmp.

On that issue, @gbtitus identified the following as being variables that are subject to this approach currently:

• [ ] CHPL_GMP
• [ ] CHPL_HWLOC
• [ ] CHPL_JEMALLOC
• [ ] CHPL_LIBFABRIC
• [ ] CHPL_LLVM
• [ ] CHPL_UNWIND

I believe we've expressed our hesitancy about the current naming scheme at times over the years, but can't recall if there's a reason that we haven't switched them other than inertia.

[bradcray]

This might be a nice issue to address before making the CHPL_LLVM by default change since it'll be a fairly high-profile environment variable that has this current odd behavior.

[ben-albrecht]

Semi-related to this (but definitely a separate design/impl. effort), I wonder if we should have consistent values for 0 || 1 chpl env settings, such as CHPL_LIB_PIC, which can be none || pic today. I can't think of any other examples of this right now, so maybe that's the only chpl env with an on/off state.

[bradcray]

I thought we had some category of boolean settings (maybe CHPL_RT_ settings? or CHPL_ settings for toggle flags on the compiler?) that were willing to accept a variety of things like 0/1, true/false, t/f. I guess the question for CHPL_LIB_PIC is whether we imagine there ever being other values that it might have than "yes" vs. "no". I'd suggest forking this off to its own issue unless someone like @ronawho or @lydia-duncan or @dlongnecke-cray has a strong argument in favor of the current behavior being right/ideal.

[gbtitus]

We do have standardized support for boolean CHPL_RT_* environment settings, which might be what you were remembering there. CHPL_RT_OVERSUBSCRIBED is used quite a lot in our testing and is the only documented one. But those are strictly for execution-time parameterization, not compile-time.

[ben-albrecht]

Filed a new issue for boolean env vars: https://github.com/chapel-lang/chapel/issues/16382