I really appreciate the help! > 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,
> 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".) Ok, I agree. I will start using that term. The "-D" option that I proposed would be the "build root" > 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. My m5build scheme works the way it does just because I was wrapping the existing stuff. It's also why I haven't really pushed it out there much. That said, my goal with a new framework would be to get rid of build_opts, and fix the names, so it wouldn't be this bizarre mapping. 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. > (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"? > Though IIRC optparse will > work with the minimum unique prefix of the arg--is that true?--in which case > maybe it's moot.) I don't know if it can or not. I could certainly support either, but I have no problem switching to the singluar form. > 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. I completely agree. More on this below. > 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. Right. > 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. Right, and since it is a global sticky option, you have to create another build root if you want to have two options available at once. This is fundamentally easy to do. > 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). Well, by saving sticky options, you will not regenerate the config/*.hh files if you only specify the sticky option the first time. So, let's say you create a build root for FAST_ALLOC_DEBUG, you'd only have to define it once if you use the sticky option. Otherwise, if in a subsequent build you forgot to include the FAST_ALLOC_DEBUG, SCons would generate a new config/*.hh file and would do a rebuild. So, I do think these have value. (Am I making sense, or do I misunderstand something?) > 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. Things will get a bit messier in the new system, because this particular file for example will not be in the ALPHA_FS subdirectory. Since the tagged.c file is ISA/emulation agnostic, it would be in build/BASE/mem/cache/prefetch/tagged.o. Something things in O3 CPU may be in every build/<ISA>/cpu/o3/foo.o while others might be in every build/<ISA_EMUL>/cpu/o3/bar.o Was that clear before? Does it make sense? > 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? > 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. Just to be clear, if we get rid of the build_opts stuff, then it doesn't really work at all while at the same time making it really easy to create a "-D" option that just works right. > 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. > 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. No, this is great. I want some confirmation that I'm going in a reasonable direction before I really rip things apart. While from the user perspective the changes won't be all that huge, from a code/developer perspective, lots of things change. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
