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
The CRYSTAL_OPTS environment variable was introduced to allow a global configuration of compiler options in a shell environment to affect every command running the Crystal compiler. I think it would be more appropriate to rename the environment variable to CRYSTAL_BUILD_OPTS to reflect that intention.
It can technically be used for any compiler option, but the intended use case is particularly sharing build configuration options. The use case of exporting the configuration as a permanent environment variable breaks with options that are not supported by all commands.
Build options are shared across a number of different compiler commands (build, run, spec and others) and thus work quite well as a global configuration.
However, there are some differences between the "full" set of build options and the so called "simple compiled options". And available options are also context-specific. So some commands just don't support all build options. But that's okay, we just have to make sure these commands accept all options allowed for CRYSTAL_BUILD_OPTS and simply ignore the values of unsupported ones (instead of failing which would happen when an unsupported option is passed as a CLI argument).
I'm not sure what should happen with CRYSTAL_OPTS afterwards. Of courese, we'll have to support it more or less in the same way as it currently works at least until Crystal 2.0. After that, we could remove it or change its semantics. Frankly, I don't see much reason for a generic environment variable that just works as an alternative to CLI arguments. So without additional use cases, I'd probably remove it. But I think that's a topic for a follow-up discussion.
I have extracted all possible options from the create_compiler method (minus those that are clearly targeted for specific compiler commands).
Probably, they should all be accepted for CRYSTAL_BUILD_OPTS.
The
CRYSTAL_OPTS
environment variable was introduced to allow a global configuration of compiler options in a shell environment to affect every command running the Crystal compiler. I think it would be more appropriate to rename the environment variable toCRYSTAL_BUILD_OPTS
to reflect that intention.It can technically be used for any compiler option, but the intended use case is particularly sharing build configuration options. The use case of exporting the configuration as a permanent environment variable breaks with options that are not supported by all commands.
Build options are shared across a number of different compiler commands (build, run, spec and others) and thus work quite well as a global configuration.
However, there are some differences between the "full" set of build options and the so called "simple compiled options". And available options are also context-specific. So some commands just don't support all build options. But that's okay, we just have to make sure these commands accept all options allowed for
CRYSTAL_BUILD_OPTS
and simply ignore the values of unsupported ones (instead of failing which would happen when an unsupported option is passed as a CLI argument).I'm not sure what should happen with
CRYSTAL_OPTS
afterwards. Of courese, we'll have to support it more or less in the same way as it currently works at least until Crystal 2.0. After that, we could remove it or change its semantics. Frankly, I don't see much reason for a generic environment variable that just works as an alternative to CLI arguments. So without additional use cases, I'd probably remove it. But I think that's a topic for a follow-up discussion.Previous discussion: #11922 (comment)
The text was updated successfully, but these errors were encountered: