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
