Quoting Ali Saidi <[email protected]>:
On Feb 22, 2011, at 5:25 PM, Gabe Black wrote:
Like I said, why can't you just do that with a simple bash alias that
appends the options to the binary? Or a wrapper script? Why make a new
tool when an existing one works just as well?
I don't think any of those mechanisms are that great. Wrapper
scripts normally muck with job control, stdin, & stdout and bash
aliases assume you're using a particular shell. I think aliases are
just magic and will cause a lot of confusion (e.g. looking i'm just
running X, never mind your shell is secretly substituting something
else without telling you). If you're in the unfontunate situation of
having multiple csh/bashrc files depending on what machine/cluster
you're on (i do) you have to try and keep those in sync rather than
just keeping all your m5 setting in sync.
Finally, the last thing I want is my m5 command line to be even
longer than it is now. They already wrap a couple of times on a
terminal. Isn't this akin to saying, why have a .vimrc? Yes i can
pass all the settings I have in my .vimrc on the command line to
vim, but why would I want to?
The more I think about it the more I like a configs.py or whatever
you want to call it. It lets you be very simple and should provide a
single place to change any environment like settings and then there
won't be any random environment variables or other things grabbed in
an adhoc fashion in the scripts.
So basically what I'm worried about is creating a new, m5 only rats
nest perhaps like those rc files you have to deal with. If we allow
multiple files that cascade we have that problem, but if we don't then
it's harder to have per machine settings that reflect the local file
system layout, for instance. If we have per machine settings at all,
they might cause unanticipated problems because they change things
your batch job or whatever wasn't expecting.
As far as your .vimrc example, I think you have a point. That's an
example of where this sort of thing is useful. The problem I see with
that, though, is that we already have a programmable configuration
system in the form of the simulation scripts. This is just for the
little stuff you'd configure through the main binary which is much
more limited than all the stuff you can control with a .vimrc.
What makes your command line so long? Is it options for the binary
itself, or for the simulation script? This sort of thing won't help
for the later, at least not without making it a bit of a hack. The
only thing that makes my command line long as far as the binary
section are any traceflags I'm turning on, and I doubt you'd want to
force those on all the time. You're usage may be very different, of
course.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
