On 02/22/11 09:33, nathan binkert wrote: >> That said, using python to generate python to put in a hidden directory to >> read with python embedded in a binary is, in my opinion, WAY more >> complicated than the problem warrants. The generating script would have to >> be fairly smart too so you could quickly update particular fields, remove >> previously set defaults, etc. >> >> How about a file with key value pairs separated by equals signs. Those would >> be used as the defaults when the options were set up, and that would be the >> whole deal. If somethings doesn't make sense as an option to the m5 binary, >> it wouldn't go in that file. > This is probably right. Though I think the name = value file should > either be python code (this is more or less how it is now since you > just do name=value and not much else.) or a .ini (because there's an > easy to use parser and it's a well known file format). > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev
You know, I thought about this more, and I think we're sort of going down a rabbit hole here. If we use a .ini file, then there's not a good way to do things like build up an M5_PATH to have multiple components. If we make it more python like, then we add a new avenue/dimension for complexity, more surface area for compatibility issues, etc. Do values that are set for the machine get taken into consideration? What happens if you run on a cluster and somebody has a file that that screws up your run? Do you then have to add all the options to the command line anyway to be safe? Then you have to ask is this actually useful? In some circumstances I think functionality like this (setting specialized defaults) could be useful, but in the thousands of times I've invoked M5, I've never wished I could change the defaults. Also, I think the same effect could be had through a wrapper script, shell alias, etc. So in the end I think we should scrap this default changing stuff. I think it's at least partially an example of widgetry for widgetry's sake. I also still like the M5_PATH environment variable. It's analogous to PATH which people already understand and does a similar job. If there really are a bunch of different ways of setting up the path then we should try to consolidate them, but this seems to be the one that makes the most sense. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
