Rubinius does not accept -X19 via RUBYOPT #1861

Closed
postmodern opened this Issue Aug 15, 2012 · 7 comments

4 participants

@postmodern

I noticed that I cannot pass -X options to rubinius via the $RUBYOPT environment variable; unlike with JRuby.

$ export RUBYOPT="-X19"
$ rbx --version
rubinius 2.0.0dev (1.8.7 49fcc237 yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]
An exception occurred processing command line arguments
    invalid option in RUBYOPT: -X (RuntimeError)

Backtrace:
  Rubinius::Loader#handle_rubyopt at kernel/loader.rb:507
         Rubinius::Loader#options at kernel/loader.rb:439
            Rubinius::Loader#main at kernel/loader.rb:822
$ unset RUBYOPT
$ rbx -X19 --version
rubinius 2.0.0dev (1.9.3 49fcc237 yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]
@brixen
Rubinius member

It's not a RUBYOPT. You need to specify RBXOPT=-X19.

@brixen brixen closed this Aug 16, 2012
@ddd

My question is, why when all other implementations keep (or try to keep) options passing using the same expected variables that one would expect to use (such as jruby, and MRI) does RBX change from the expected? One would think that, since this is an implementation of Ruby, known standardized vars would be used across the board. Why does RBX differ? is there some technical reason behind this, or is this merely a 'differentiation' point?

@evanphx evanphx reopened this Oct 16, 2012
@evanphx
Rubinius member

Originally we did this because RUBYOPT was supposed to be options that all ruby implementations support. But 1.9 allows for implementation specific options in RUBYOPT anyway, so I think it's fine to add the ability to parse RUBYOPT for -X options as well.

@brixen
Rubinius member
  1. There is no standardization of extended options.
  2. There are order-sensitive aspects of processing the -X options. We cannot replace RBXOPT with RUBYOPT because we cannot process RUBYOPT at the time when we need to process RBXOPT
  3. Mixing processing of RBXOPT and RUBYOPT leads to significant complexity

I am adamantly against mixing RUBYOPT and RBXOPT options. If a tool is intended to do things with Rubinius, it should know the difference between them.

What is so difficult about setting RBXOPT that it requires Rubinius to deal with this significant complexity?

@postmodern

@brixen all good points. I think the issue is that tool authors must add additional logic just to support Rubinius, instead of treating all Rubies equally.

I would love to see a common extended option syntax supported by JRuby and Rubinius. Also, I wonder how JRuby handles parsing --1.9 out of RUBYOPT.

@brixen
Rubinius member

There is no point in standardized extended options. The point of extended options is that they aren't available in Ruby. If something is going to be added to Ruby, it can be a normal Ruby option. The extended options are for implementation-specific behavior.

I will do everything in my power to make language modes go away. They only exist right now because insufficient modularization forces us to have to do too much source level jiggering to support completely separate builds. The mixing of language modes has been a humungous headache for me.

You are complaining about one extended option flag, the language mode.

How JRuby does it is immaterial to this discussion.

@postmodern

@brixen well if you standardized on an extended option syntax (ex: -Xname=value) you could do a two step parsing of RUBYOPT.

The only reason I bring up JRuby is they appear to support implementation specific options in RUBYOPT, therefore it is not impossible. Also, I don't think anyone is "complaining" here, just merely pointing out behaviour that is oddly specific to Rubinius.

I'm also curious how Rubinius will handle Ruby 2.0 vs. 1.9?

@brixen brixen closed this Oct 22, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment