(inline)
One psychological solution would be to reduce the amount of output from
SLICC, making it a less obvious target for annoyance when you're waiting
for
a build...
Along this same line of thought, it may be easier in the interim to print
out something like Continuing build ... or SLICC
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of nathan binkert
Sent: Thursday, April 21, 2011 5:53 PM
To: M5 Developer List
Subject: Re: [m5-dev] what scons can do
Maybe so... I think there's a subconscious impression
Is that 1%/99% a statement of a clean build for m5.fast? I think the much
more common case is you edit one .cc file and rebuild. In that situation, it
sure seems like a lot more than 1% of the time is spent by scons regenerating
and reanalyzing SLICC files.
Whatever it may be, it sure
Quoting nathan binkert n...@binkert.org:
Anyway, it seems like it would be useful to be able to have multiple
binaries that can be built by scons, specifically the utility stuff and
unit tests. That way we could avoid having a hodge podge of small build
systems which are either isolated or not
A mechanism where I can say binary foo needs file bar, and then when I tell
it to build foo it build's it with bar, and bar doesn't get mixed in to
other things. I think you're new widget that was like mercurial patch guards
would help with that, right? You could have a guard for each extra
Quoting nathan binkert n...@binkert.org:
A mechanism where I can say binary foo needs file bar, and then when I tell
it to build foo it build's it with bar, and bar doesn't get mixed in to
other things. I think you're new widget that was like mercurial patch guards
would help with that, right?
That doesn't really fit with how the ISA files work. They get broken into an
AST, but that gets consumed as it goes,
Does it have to be?
and it has a lot of anonymous python
in it that just gets executed somehow. I want to move more into the python,
so the AST will be less and less useful.
On Thu, Apr 21, 2011 at 2:11 PM, nathan binkert n...@binkert.org wrote:
Running SCons twice in the way you suggest would be FAR slower than
just running SLICC and the ISA parser twice the way we do.
Are you sure? Running SLICC every time just to get a (typically unchanging)
list of files is
Are you sure? Running SLICC every time just to get a (typically unchanging)
list of files is not exactly instantaneous, and the names of the SLICC
output files hardly ever change. What about this approach:
It is pretty fast (and this includes starting the python interpreter)
0.48s user 0.03s
Quoting nathan binkert n...@binkert.org:
That doesn't really fit with how the ISA files work. They get broken into an
AST, but that gets consumed as it goes,
Does it have to be?
Making it not work that way would likely be very painful. The parser
part is finicky (like they all are in any
On Tue, Apr 19, 2011 at 3:00 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I was looking at some of the stuff in util, and it occurred to me that
the m5 utility program is cross compiled using different Makefiles for
different architectures. Statetrace used to be like that (sort of), but
On Tue, Apr 19, 2011 at 3:13 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Caching the list of generated SLICC files sounds like a good idea to
me. I'm not sure this would require recursive scons invocations,
since we manage to build the list dynamically already without that. I
Quoting Steve Reinhardt ste...@gmail.com:
On Tue, Apr 19, 2011 at 3:13 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Caching the list of generated SLICC files sounds like a good idea to
me. I'm not sure this would require recursive scons invocations,
since we manage to build the
13 matches
Mail list logo
