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
