(Sorry if this already went through. I accidentally sent it from a different account the first time, and I think it got silently rejected by the mailing list, or at least I couldn't find it in my email.)
Hey folks. I've been thinking about how build configuration is handled right now. Mostly this is done using files in build_opts (selected by the name of the build subdirectory), and setting variables on the SCons command line. This can be a bit tricky because there are variables which have sticky values, variables which come from the environment, etc, and it's not always clear what they are, what they do, what value they have, why, what values they could have instead, etc. One feature we have now which helps, is that if you print out the help message, our script will also dump all the config values. This is good, but it's a little hidden, and is a big wall of text which can be confusing or overwhelming itself. What I would like to do is to add some sort of explicit configuration step/mechanism (think something like make config for the linux kernel) which would let you browse around the config options, give them help text, etc, and let you manage them in a more friendly environment than passing them on the command line. This would also provide a lot cleaner mechanism for updating variant specific variables. For instance, if you want to update the CPU list for just x86, you'd need to do something like scons CPU_MODELS=.... build/X86/gem5.opt. You would have to update the setting as part of a build, and the build would have to specifically be part of build/X86, even if you didn't want to build now, or wanted to build something else, like maybe gem5.opt for all the arches. The downside to making the configuration mechanism more powerful is that people will probably take advantage of that, and the number of ways gem5 could be built will go way up (again, think make config for the linux kernel). On the plus side, this will make a mechanism like letting people turn on/off individual models, build parts of gem5 as modules, etc, *way* more user friendly than having 10,000 USE_BLAH_BLAH flags on the command line. Obviously there are many steps between here and there and I don't expect to get there in one huge leap. Given that, what do people think of this as far as a general direction? Gabe
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
