* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o
That wouldn't be ideal because we would need to emulate everything
Object() is doing to get the c compiler and options right.
Here is take two on the hg version diff. It creates a file which is
dependent on all the other objects in the system. So if you make a
change to the repository nothi
The kernel is now getting to a point where it's trying to calibrate
the timer in the local APIC against the TSC register. In order to mimic
that, I'm going to need to create an event to fire when the timer is
supposed to go off. This is enough of an impetus to separate the local
APIC into it
We could just provide our own action that is both a file generation
and a compile.
On May 21, 2008, at 2:05 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
We can't because the date is created by the compiler with the
__DATE__ __TIME__ macros. The only way to do something like this
would be creat
We can't because the date is created by the compiler with the __DATE__
__TIME__ macros. The only way to do something like this would be
create a dummy file that we write a string to in the SConscript. We
can set it's dependencies to be all other objects, but I don't know if
we can remove th
What I was talking about is basically that except that it's the upstream
changeset. I think Ali pointed out in an email I can't find at the
moment that if someone sends output to the list, we have no idea what
they started with if we only have their local most recent changeset.
Gabe
Nathan Bi
What exactly are you trying to do? Stick the changset in the output?
If so, do it how we do the date.
On May 21, 2008, at 1:12 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
This diff stamps a file adds the mercurial id to the output, however
Nate complained that if the revision in the working d
The idea was that this would sit in the head which is the final resting
place for changesets. You wouldn't pull changesets in and out all the
time, and if you're going forwards or backwards within revisions from
the head you probably want to recompile anyway. The revisions you're
making locally
This diff stamps a file adds the mercurial id to the output, however
Nate complained that if the revision in the working directory changed
(which could happen if you qdeleted a patch) then you would have to
recompile (although not much just a re-linking). Something that could
fix that (that
I've been thinking about how this could actually be done, and it
seems to me that there could be a hook in the head (hooks are
propagated, right?) which adjusted a header file every time a changeset
was pushed into the head to have that hex value in a variable. The
adjustment to the header f
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o
11 matches
Mail list logo
