On Thu, Feb 12, 2009 at 11:35 AM, nathan binkert <[email protected]> wrote:
> > As far as location, I agree src is the wrong place... how about under > util, > > like util/scons or util/sconshelp? > That also doesn't seem to fit for me, but if a top level directory is > the wrong place, util is the best. I still think I like buildlib at > the top better, What's your objection to putting it under util? Just curious... > This brings up the related question, do we want to preserve the > existing names ALPHA_SE, etc. or do we want to make them lower case, > or something else? I ask because this would be the time to change > things. I don't have a strong feeling... I'm used to the uppercase, but I don't remember why it ended up that way, and lowercase would save some wear and tear on the shift key. > > (BTW, this is really minor, but using the singular instead of the plural > for > > the m5build args seems much more natural to me. > > What specifically are you referring to? You mean that it should be > "--isa" or "--binary" instead of "--isas" or "--binaries"? yea, and --emulation instead of --emulations > > Another option (probably instead of using global sticky scons opts) > would be > > to leverage the config/*.hh files more... [...] > Well, by saving sticky options, you will not regenerate the > config/*.hh files [...] (Am I making > sense, or do I misunderstand something?) That makes sense, and it's what I meant to begin with when I said this option would be instead of using global sticky opts. I don't think re-reading the config/*.hh files is actually the way to go; it was just one of those ideas I had on the road to my final conclusion and I thought I'd leave it in my email even after I decided it probably wasn't the best just in case you hadn't thought of it and saw some reason it might be preferable. > > If we have a limited set of > > legal build dir names (<ISA>_<FS|SE> again) then this becomes easier; the > > problem now is that these are allowed to be arbitrary strings, which is > why > > you have to look for "build" and then use the name of the next dir in the > > path. > > True, but I we're concluding that this isn't of any real benefit, right? yea, I think those names have to have concrete meaning now that we're using them to segregate different classes of objects based on what their dependencies are. > > I guess m5run is OK too but I'm not sure I'd use it... I generally run > gdb > > inside of emacs. Having the tracediff functionality integrated there is > > nice but the duplication of code (in two different languages) is > suboptimal. > > I think it largely replaces/deprecates the existing tracediff if we do > choose to go with the m5build stuff. I think that even if you didn't > use the -g flag to m5run, that people might it handy to say m5run -o > work instead of ~/m5/work/build/ALPHA_FS/m5.opt. I believe that this > is especially true for those of us that build their code in a > directory other than $M5/build, which I encourage anyone using NFS or > any other kind of distributed filesystem to do. Source in one place > shared over NFS, build directory on a local disk. Comples are way, > way faster. I actually have a bunch of elisp code that actually > integrates with m5run and m5build. It's pretty crude, so I have to > clean it up, but you might really like that. I haven't used NFS in a long time, but your argument makes sense to me. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
