> Just to be a little more specific: I'm not saying that we need to develop a > general compile-time configuration mechanism before we merge these changes > back in. I'm fine with something as simple as leaving the existing SE/FS > distinction in the SConscripts, but having it such that the only > distinction between the SE and FS builds is that the latter includes > devices etc. (and whatever else constitutes the 31% extra work) but the > former doesn't. We can rename FS to something else to indicate that it's a > superset. Or we can rename them both.
How would we deal with regressions? I'd definitely want to run SE regressions on the unified compile, not on the SE one. Would we require developers to compile both SE and FS before committing? (I hope not). > My discussion of the general compile-time mechanism is just to emphasize > that the maintenance of this one aspect of the current SE/FS difference is > a stopgap replacement for this alternate ideal, not a perpetuation of the > now-meaningless distinction that Gabe has worked so hard to eradicate, so > that he doesn't accuse me of bitterly clinging to the past... Ok, but I'd really hate to see this delay Gabe long enough that we don't ever get it into the tree. Gabe, do you think it'd be easy to cook up what Steve is talking about? (Or does it already work in your tree?) Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
