The basic problem is this: Ruby.define_options(parser) adds Ruby-specific options to the parser. It also does "import PROTOCOL".
When running in classic mode, if you always do the above, it will barf on "import PROTOCOL" because ruby has not been compiled and it will say things like, "wtf is RubyCache?". So, you can't do Ruby.define_options by default. So then, you can hide it behind an "if options.ruby", but then you'd have to have already parsed the options to find out if options.ruby is set before then adding ruby-specific options to the parser. Thus, the parsing will get confused, e.g. if you do "....--ruby --topology foo" it will say, "wtf is --topology?" because in the initial parsing to find out if you are using ruby, topology has not been added to the parser yet. So, the lowest-tech option is the one I proposed, which just pushes all ruby-specific options behind a "--" and does a second round of parsing on args beyond the "--", but this puts burden on the user. Other options, such as moving to other parsing packages will put burden on us to do some rejiggering, and potentially the user as well if argparser requires 2.7 and the user doesn't already have it. We could also just re-separate the two files in such a way that there is not gross code duplication (which was why I merged the two in the first place), or have all builds automatically build Ruby stuff even if you are running in classic mode (simple solution, overkill results?). Lisa On Wed, Jul 6, 2011 at 10:08 AM, Steve Reinhardt <[email protected]> wrote: > Can't we just resolve whatever the conflicts are? > > Or we could go back to having a ruby_se.py, but have it be a link to se.py, > and use sys.argv[0] to decide whether to look for the ruby args? (Not > pretty, but sort of backwards compatible without duplicating code.) > > I don't fully understand the problem, which can actually be somewhat > liberating when it comes to proposing solutions :-). > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
