> I prefer to retain it. There are places where we check if RUBY is set or > not, and checking for whether PROTOCOL is set or not, would not make sense, > though it would yield the same information.
What's the point of it? It's just redundant. The existence of both variables is simply an accident of history during the merge process. Basically, we should just check that PROTOCOL is in env or that PROTOCOL is not None and that would signify that we've got ruby compiled in. Having two variables doesn't gain us anything. We could rename PROTOCOL to RUBY_PROTOCOL. I don't care enough to fight, I just think that reducing the number of compile time variables is always a good thing. All this said, I think that actually the correct thing to do for se.py is to essentially do an "if 'PROTOCOL' in env" then add a --ruby option to the command line. Then do an "if '--ruby' in sys.argv" check to determine if the ruby options should be added. I know this is convoluted, but the classic memory system does exist even when ruby is compiled in, and without doing this in two steps you can't use the classic memory system if you have ruby compiled. That IMHO makes no sense. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
