> Is there any particular reason that RUBY is a global build option, and > not a per-build one? (That is, I can't build MIPS_SE w/o Ruby and > then build ALPHA_SE or even ALPHA_SE_MOESI_hammer with Ruby in the > same build directory.) Nate, you're the one that added RUBY to > global_sticky_vars and not sticky_vars... was there a reason for this? > (See http://repo.m5sim.org/m5/rev/ba6fe02228db.) Only that I'm eventually trying to get rid of the whole sticky_vars thing and get to what is in effect global_sticky_vars. The reason I'm trying to do that is that I would eventually like to get to the point where we're not building stuff multiple times if we can avoid it. That said, for this case, it doesn't make much of a difference, so I won't object. I really would like to avoid us getting into the place where one build dir supports all different sorts of build options, making it more difficult to avoid duplicate compiles.
> Unless there's a good reason, I'm going to move it to sticky_vars so I > can force the builds that imply Ruby (like ALPHA_SE_MOESI_hammer) to > turn Ruby on... otherwise if the global RUBY flag is false you end up > building them anyway and get what I believe is N functionally > identical copies of ALPHA_SE that each insist on having all the > regressions run on them. Go for it. > OK, I see that not having it as a global option causes the check in > src/mem/ruby/SConsopts to fail, but I commented that out and things > seem OK. Yeah, you just get extra options that don't mean anything not too big a deal. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
