Steve,
I'm primarily writing you because you're the only other serious scons
hacker on the dev team, but I'm including the dev list so everyone can
see what I'm thinking and perhaps comment. For those of you who don't
really care about the details of scons, you might still find the
attached patch handy as a nice set of utilities for helping you
compile and run m5.
1) First, I want to create a python package full of helper stuff for
SCons. The big question is, where should it go? I can put it in the
top level directory and call it buildlib or something like that. I'd
really rather not start the directory name with s, c, t, or u since
that will harm tab completion. I don't put my build directory in the
source directory, so I can imagine that others might even not really
like it to start with b. Any ideas? I could also put it in
src/python, but that might be too buried and since it really isn't
part of the source tree, it seems like the wrong place.
2) Do you think that build_opts stuff really helps? There are really
two things that the build_opts allows you to do. One is define the
ISA and emulation, and the other is define some other compile time
parameters such as SS_COMPATIBLE_FP or FAST_ALLOC_DEBUG. In practice,
I think users don't touch this, and developers only use the former to
provide new ISAs on a semi-permanent basis. If the latter is still
useful, I think we need to separate these two ideas because I think
that the new framework will require things to work a bit differently
so that options can import other options. e.g., there should be
something called ALPHA, something called SE, and ALPHA_SE should
include both of those. (This way I can construct the proper scons
environments and simplify the build.) For the ISA and emulation
parameters specifically, I expect to use something a bit more pythonic
remove them from the SCons options entirely. I'd probably just have a
subpackage in buildlib that describes the various ISA/Emulation
options, so there will be simple files that developers can modify as
we work with more ISAs. Once I do this, I wonder if build_opts is
really beneficial. If it is, it could be applied to a whole build
directory with a command line parameter instead of being part of the
build directory name. This would fit in with the stuff I've written
below.
3) right now, we parse the scons command line arguments quite a bit to
figure out what to build and where to build it. For example, if we're
not using the normal build directory, we parse the target to figure
out where the build directory is. This would allow us specify several
different build locations at once build1/build/ALPHA_FS,
build2/build/ALPHA_SE. In practice, I see no utility in this. I
suspect that we would continue to want to specify which binary to
build and thus parse that part of the command line. For the where to
build part, I just add a command line parameter -D perhaps that
specifies where the build should go? This would shorten command lines
quite a bit.
4) The previous question gets into a utility that I wrote for myself
(attached) that greatly simplifies building and running m5 by helping
you build the right command lines. I can contribute these as-is, but
I'd actually prefer to move much of the functionality directly into
scons. This would result in a scons command looking like:
scons -D my build dir --isas=alpha,sparc
--emulations=fullsys,syscall --regression=quick, instead of the crazy
command lines that we have right now (I will continue to support the
crazy command lines because that is inherently how scons works).
A big part (for me at least) of m5build and m5run is that they allow
you to label source tree, build directory pairs with labels and you
can build or run a labeled directory from anywhere. Much of this
can't really live in the SConstruct file because it's really used to
locate the sconstruct file itself.
I know this is a lot, but I'd love to hear your thoughts.
Nate
build: Add utilities for helping you build scons command lines and run m5.
The m5build script does two things, it helps you build m5 in any build
directory from any directory. The second thing it does is simplify the
construction of the scons command line. For example, you can say
% m5build --all work
This will construct a scons command line that will use your work tree
and build all variants of the code. (These things are configurable and
there is help information in the files.)
The m5run script simplifies building m5 command lines in that you can
say something like:
% m5run -g work m5 options
This will go and find the debug binary for the work tree and run it under
gdb passing the m5 options that you specified.
diff -r 5645632d594c util/build/dotm5.py
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/util/build/dotm5.py Wed Feb 11 12:51:40 2009 -0800
@@ -0,0 +1,48 @@
+# Copyright (c) 2006-2009 The Hewlett-Packard Development Company
+# All rights reserved.
+#
+# Redistribution and use in
