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)
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]
It's not a RUBYOPT. You need to specify RBXOPT=-X19.
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?
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.
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?
@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.
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.
@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?