18206, "bradcray", "Update docs to have people use '--print-chpl-settings' rather than 'printchplenv'", "2021-08-11T21:00:31Z"
I often forget about this flag, but chpl
supports a --print-chpl-settings
flag that is a lot
like running util/printchplenv
. This issue proposes that we update our guidance for users
to have them "send us the output of your compile-line with --print-chpl-settings
added to
the end" rather than having them run printchplenv
. The basic idea is:
-
printchplenv
may not be particularly familiar to users, particularly if they haven't done
their own Chapel install and it's not in their path, or they don't know where $CHPL_HOME
is (e.g., in a homebrew install, it can be hard to find); in contrast, they're already familiar
with how to run the compiler if they're filing a but like this. - since the compiler's notion of the environment may depend on things like other flags
passed to it, doingchpl [all the args I was already passing] --print-chpl-settings
would
give a better indication of how the compiler views the environment than how the command
line prompt views it. As of #18194, it may also make decisions that aren't immediately
obvious from the command line like "I wasn't built with LLVM support and the user hasn't
set CHPL_LLVM, so I'd better set it tonone
to ensure the environment doesn't infer it
to bebundled
orsystem
").
One question to wrestle with here is what we do about anonymizing the output of
--print-chpl-settings
(where today, we ask users to send us printchplenv --anonymize
).
One option would be to have --print-chpl-settings
always anonymize by default and to
have it not anonymize when in developer mode. Alternatively we could:
- stop asking users to use auto-anonymized data and just let them know that they may wish
to anonymize - support additional options or arguments like
-print-chpl-settings-anonymize
or the like