As far as location, I agree src is the wrong place... how about under util, like util/scons or util/sconshelp?
As far as everything else: to me the unifying theme is that somehow you have to associate a build directory with its compile-time options, whether that's the ISA or something more minor. (Note by "build directory" I'm talking about a specific directory, like foo/build/ALPHA_FS, not the common base of a set of build directories like foo/build. Your use of "build dir" for the latter confused me a bit. I suggest we call the latter the "build root" and not the "build dir".) Anyway, making that specific association between a build dir and the compile-time options is what build_opts does for us now. I'm not particularly wedded to it, so if there's a better way I'm fine with switching. My initial reaction is that I'm not fond of the idea of having two different ways of associating compile-time options with build dirs depending on whether the compile-time option is the ISA or not. (However, keep reading...) I think the key issue is that we have canonical names of <ISA>_<FS|SE> for "default" configs, but no naming scheme for anything else. Note that from the build_opts perspective, these names are totally arbitrary and are just the names of settings files in the build_opts directory. If you wanted to configure the X86_SE directory to build with the Alpha ISA in FS mode you could easily do that just by editing one file. Not that we need that flexibility, but it seems odd to me that with your m5build scheme you end up having to map --isa=alpha --emulation=syscall to this arbitrary string "ALPHA_SE" and then use build_opts to map that back to the corresponding compile-time settings. The challenge is that if I want two versions of ALPHA_SE, one with FAST_ALLOC_DEBUG on and the other with it off (mostly because I don't want to blow away the latter just to build the former) then I need two names and there's no standard for that. (BTW, this is really minor, but using the singular instead of the plural for the m5build args seems much more natural to me. Though IIRC optparse will work with the minimum unique prefix of the arg--is that true?--in which case maybe it's moot.) So my overall feedback is (1) the m5build script looks nice in concept and I'd be glad to see something like that integrated with our scons scripts but (2) I'd much prefer to have whatever it does be general enough to replace build_opts without losing functionality (I do on occasion use FAST_ALLOC_DEBUG) as opposed to just adding a layer of indirection on top of it. One option would be to have all the compile-time options other than ISA and emulation mode be set at the build root level... then I could still have two versions of ALPHA_SE but I'd have to create a new build root for that. Perhaps that makes sense if most of the non-ISA options impact most of the ISA-independent code; you'd need someplace separate to store the rebuilt common files anyway. OK, so now I see why you might want to move to two classes of compile-time options: those that affect all of the common base code and those that only impact predetermined subsets of code that get built independently. Getting rid of build-dir-specific compile-time options that are set via sticky scons options pretty much does eliminate the point of build_opts, I think... which would be the case if everything other than the ISA and emulation mode (which can be derived directly from the build dir name) is a global sticky option instead. Another option (probably instead of using global sticky scons opts) would be to leverage the config/*.hh files more... currently these are generated by scons to reflect the settings of the internal scons options, but never read back in (by scons). We could have our SConstruct read the config files directly if it needs to know what the settings for an existing build dir are. The whole rigmarole of saving sticky options in build/options/* is only useful for preserving non-default options settings in the face of blowing away entire build dirs, which does not seem critical to me (can't recall the last time I used that). As far as parsing the target path, the key thing is figuring out which default options to use, particularly if I specify an internal target like build/ALPHA_FS/mem/cache/prefetch/tagged.o. 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. I don't think I've ever tried to build things under two different build roots in one scons call, so I agree that that feature isn't all that useful. 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. Sorry if the email is rambling... I wrote about twice this much text in total but it was one of those where I kept figuring out new things as I was writing which made me go back and edit or replace things I had already written. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
