Well, I imagine most people will use mercurial at least to check out
the code in which case we'll have the last ID. Perhaps we want to
include the qbase revision as well incase lot of people use MQ.
Speaking of which when the repository is made available we probably
want a pretty good little e-mali tutorial that pitches the "right" way
to do things as using MQ on top of the repository. I don't really like
the idea of having a hook that introduces its own changesets into the
repository. Anything we add needs to be a manipulation of the data in
the mercurial directory.
Ali
On May 22, 2008, at 8:56 PM, Gabe Black wrote:
As I said in an email earlier, you had pointed out that if somebody
sends in the output of m5, it's nice to be able to easily tell it's
beta 4 or beta 3 or somewhere in the middle and they, for instance,
might need the cache patches without having to go back and forth
teasing out details. My gut says a lot of people won't take
advantage of mercurial so the current revision will likely be the
same as the mainline one, but it might be useful. It could also be
handy to easily tell what changesets from the mainline you're binary
was compiled with assuming you have patches on top of it. It's
something that could be handy although I'm sure we'd survive without
it.
Gabe
Ali Saidi wrote:
Why do we care about the central repository version?
Ali
On May 22, 2008, at 8:13 PM, Gabe Black wrote:
So anyway, now that we seem to have the current version in there,
what about the original question which was about the latest
mainline revision?
Ali Saidi wrote:
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 nothing will be recompiled. To
get the right info I need to use os.getcwd(). That works in the
default case but I don't know how it interacts with Nate's
compiling script. Worst case it just print the Hg revision as
"Unknown", however I can't seem to pass the SConscript root
directory to the builder that builds hginfo.cc without it setting
up a circular dependency that I can't get rid of.
Ali
On May 21, 2008, at 5:47 PM, Nathan Binkert wrote:
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 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 the dependence on
itself (it's changed so why shouldn't a new object file be
created?).
Ali
On May 21, 2008, at 4:59 PM, Nathan Binkert wrote:
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
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
didn't try) would be to remove the build dependency from that
file, but you would have to add a dependency to every other
file in the build that would execute some python that would
cause that file to regenerated.
Ali
<hgver.diff>
On May 21, 2008, at 4:08 PM, Gabe Black wrote:
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 file
would be part of the changeset so that moving around
revisions would keep it consistent, and I don't know if you
could really do it any other way. That would ensure that
unless the downstream users explicitly modify that header
file for some reason, which would be a little weird, the
output would reflect the last changeset that was stamped by
the root. One downside to all this is that that file would
change constantly and clutter the history and the repository
metadata.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
------------------------------------------------------------------------
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
