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
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
------------------------------------------------------------------------
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
