Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename CRYSTAL_OPTS to CRYSTAL_BUILD_OPTS #11943

Open
straight-shoota opened this issue Mar 28, 2022 · 1 comment
Open

Rename CRYSTAL_OPTS to CRYSTAL_BUILD_OPTS #11943

straight-shoota opened this issue Mar 28, 2022 · 1 comment

Comments

@straight-shoota
Copy link
Member

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.

Previous discussion: #11922 (comment)

@straight-shoota
Copy link
Member Author

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.

Output options

  • --format text|json
  • --no-color
  • --stats
  • --progress
  • --time
  • --verbose

Error/Warning options

  • --error-trace
  • --warnings all|none
  • --error-on-warnings
  • --exclude-warnings <path>

Code options

  • --define FLAG
  • --prelude FILE

Target options

  • --cross-compile
  • --target TRIPLE
  • --mcpu
  • --mattr
  • --mcmodel

Emit options

  • --ll
  • --emit FORMAT

Codegen options

  • --no-codegen
  • -d
  • --no-debug
  • --release
  • --static
  • --single-module
  • --threads NUM

Link options

  • --link-flags FLAGS
  • -o FILE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants