On Mon, Jan 3, 2011 at 8:38 PM, nathan binkert <n...@binkert.org> wrote:
> >> I love this and I've been wanting it for a while for your reason #1, > >> also, there are some ambiguous things where the same file is printed > >> because one is a TARGET and another thing uses a SOURCE (that always > >> bothered me.) > Glad it's not just me :-). > >>> [ CXX] ALPHA_SE/sim/main: .cc -> .do > >> My only change would be to remove the colon space. It serves little > >> purpose and makes cut-and-paste less useful. > >> > >> [ CXX] ALPHA_SE/sim/main.cc -> .do > That's a decent idea... I didn't do it that way because it makes it potentially ambiguous about where the new extension gets spliced in, but in practice that's got to be rare, and having at least one file name you can cut and paste is a win (that's one thing I wasn't thrilled with about either of my patches). > > I'm ok with it, but I still think the cases where there is a problem are > few are far between. Anyone who really has a problem should turn on the > verbose printing. > There's a huge difference in verbosity and readability between this and verbose... if Ali's patch was 0 and this is a 1, the old verbose is like 18. Not to mention that this makes it clear what the sources and targets are, which is hard to do when switching around between different command lines for different tools. > > I frequently compile many different versions of the source, and I like > to know if it's working on the .do or the .fo (so I can get an idea of > how far things are along.) If Gabe and Ali don't like this, we could > go so far as to do Gabe's idea of VERBOSE=1 or VERBOSE=2, though that > seems like overkill to me. I personally really do like this diff and > would hate to see it go. > With Nate's suggested change, for CXX lines we're really just tacking on the ' -> .o' at the end... the initial part of the line is unchanged, and the number of extra chars per line is 6 or 7. If you guys really insist, it probably wouldn't be too hard to make this controlled by an option, but I agree that it seems like overkill. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
