|
From: <sv...@va...> - 2009-07-14 04:49:27
|
Author: njn
Date: 2009-07-14 05:49:18 +0100 (Tue, 14 Jul 2009)
New Revision: 10447
Log:
Don't put the Vex SVN revision number in the preamble -- it achieves little
and is an enormous pain.
Modified:
trunk/Makefile.vex.am
trunk/coregrind/m_main.c
Modified: trunk/Makefile.vex.am
===================================================================
--- trunk/Makefile.vex.am 2009-07-14 04:24:18 UTC (rev 10446)
+++ trunk/Makefile.vex.am 2009-07-14 04:49:18 UTC (rev 10447)
@@ -61,52 +61,19 @@
rm -f auxprogs/genoffsets.s
#----------------------------------------------------------------------------
-# vex_svnversion.h
+# main_vex_svnversion.h
#----------------------------------------------------------------------------
-# The contents of vex_svnversion.h depends on the Vex revision number. The
-# ideal way to deal with it would be if SVN had post-update hooks: we'd
-# generate/regenerate it every time we did "svn co"/"svn up", and otherwise
-# never delete it or regenerate it.
-#
-# But SVN lacks post-update hooks. So instead we generate it when building
-# (it's in BUILT_SOURCES) if it's not present (we test for that in the
-# generation rule), or if 'make version' is run. (Thus it can get
-# out-of-date when developing; the 'make version' target lets that be
-# remedied manually.) Otherwise, we never delete it or regenerate it (in
-# particular, it is not present in CLEANFILES). Furthermore, at 'make dist'
-# time, we regenerate it, and copy it into the dist tarball, thus ensuring
-# the distributed version is up-to-date. Note that if a user manually
-# deletes it and rebuilds, or does 'make dist' from a distributed version,
-# it will be regenerated incorrectly, containing the string "exported"
-# instead of the SVN revision number.
-
BUILT_SOURCES += priv/main_vex_svnversion.h
-# Generate it at build time if not present. Nb: generating a file and
-# putting it in $(srcdir) rather than $(builddir) seems like bad form. But
-# because this file won't be regenerated post-distribution, then it's more
-# like a non-generated file and so is reasonable to put in $(srcdir).
-priv/main_vex_svnversion.h: version
- if [ ! -f priv/main_vex_svnversion.h ] ; then \
- mv $(top_srcdir)/vex_svnversion.h \
- $(srcdir)/priv/main_vex_svnversion.h; \
- else \
- rm -f $(top_srcdir)/vex_svnversion.h; \
- fi
+# The contents of this file don't matter, as we don't call LibVEX_version()
+# from Valgrind.
+# Nb: generating a file and putting it in $(srcdir) rather than $(builddir)
+# seems like bad form... this should be fixed if VPATH builds are made to
+# work.
+priv/main_vex_svnversion.h:
+ echo "\"version\"" > $(srcdir)/priv/main_vex_svnversion.h
-# Regenerate it and copy it into the dist tarball at 'make dist' time.
-dist-hook: version
- mv $(top_srcdir)/vex_svnversion.h \
- $(distdir)/priv/main_vex_svnversion.h
-
-# Generate it.
-version:
- cat quote.txt > $(top_srcdir)/vex_svnversion.h
- svnversion -n . >> $(top_srcdir)/vex_svnversion.h
- cat quote.txt >> $(top_srcdir)/vex_svnversion.h
- cat newline.txt >> $(top_srcdir)/vex_svnversion.h
-
#----------------------------------------------------------------------------
# libvex-<platform>.a
#----------------------------------------------------------------------------
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2009-07-14 04:24:18 UTC (rev 10446)
+++ trunk/coregrind/m_main.c 2009-07-14 04:49:18 UTC (rev 10447)
@@ -803,8 +803,8 @@
/* Core details */
VG_(message)(Vg_UserMsg,
- "%sUsing LibVEX rev %s, a library for dynamic binary translation.%s",
- xpre, LibVEX_Version(), xpost );
+ "%sUsing LibVEX, a library for dynamic binary translation.%s",
+ xpre, xpost );
VG_(message)(Vg_UserMsg,
"%sCopyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP.%s",
xpre, xpost );
|
|
From: Ashley P. <as...@pi...> - 2009-07-14 22:14:21
|
On Tue, 2009-07-14 at 05:49 +0100, sv...@va... wrote: > Log: > Don't put the Vex SVN revision number in the preamble -- it achieves little > and is an enormous pain. That's a big chunk of the VPATH patch gone out of the window right there, thank you. > +# The contents of this file don't matter, as we don't call LibVEX_version() > +# from Valgrind. > +# Nb: generating a file and putting it in $(srcdir) rather than $(builddir) > +# seems like bad form... this should be fixed if VPATH builds are made to > +# work. > +priv/main_vex_svnversion.h: > + echo "\"version\"" > $(srcdir)/priv/main_vex_svnversion.h Can't we just do away with this header file all together, automatically generating it with static contents seems a little odd. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-14 22:21:53
|
On Wed, Jul 15, 2009 at 8:14 AM, Ashley Pittman<as...@pi...> wrote: >> +# The contents of this file don't matter, as we don't call LibVEX_version() >> +# from Valgrind. >> +# Nb: generating a file and putting it in $(srcdir) rather than $(builddir) >> +# seems like bad form... this should be fixed if VPATH builds are made to >> +# work. >> +priv/main_vex_svnversion.h: >> + echo "\"version\"" > $(srcdir)/priv/main_vex_svnversion.h > > Can't we just do away with this header file all together, automatically > generating it with static contents seems a little odd. It is odd. The problem is that Vex can be built standalone as well as part of Valgrind. In Valgrind we now never call LibVEX_version() so we can use a dummy version of that file, but for standalone Vex builds the svnversion stuff is still present. So to get rid of it you'll need to convince Julian to do away with LibVEX_version() altogether. Nick |
|
From: Ashley P. <as...@pi...> - 2009-07-15 09:50:00
|
On Wed, 2009-07-15 at 08:21 +1000, Nicholas Nethercote wrote: > On Wed, Jul 15, 2009 at 8:14 AM, Ashley Pittman<as...@pi...> wrote: > >> +# The contents of this file don't matter, as we don't call LibVEX_version() > >> +# from Valgrind. > >> +# Nb: generating a file and putting it in $(srcdir) rather than $(builddir) > >> +# seems like bad form... this should be fixed if VPATH builds are made to > >> +# work. > >> +priv/main_vex_svnversion.h: > >> + echo "\"version\"" > $(srcdir)/priv/main_vex_svnversion.h > > > > Can't we just do away with this header file all together, automatically > > generating it with static contents seems a little odd. > > It is odd. The problem is that Vex can be built standalone as well as > part of Valgrind. In Valgrind we now never call LibVEX_version() so > we can use a dummy version of that file, but for standalone Vex builds > the svnversion stuff is still present. So to get rid of it you'll > need to convince Julian to do away with LibVEX_version() altogether. Couldn't this just as easily be done via a #define, -DMAIN_VEX_SUBVERSION=0 or something? Even better would it be possible to put the version string in the define itself? Something like -DVER_SUBVERSION=`svnversion` when building VEX standalone and -DVEX_SUBERVSION=version in valgrind. There does seem little point in having this function in Valgrind if it's return value is a hard-coded meaningless string, I'm not aware of what other projects VEX works with so can't comment on the ABI issue there. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-16 22:43:48
|
On Wed, Jul 15, 2009 at 7:49 PM, Ashley Pittman<as...@pi...> wrote: > > Couldn't this just as easily be done via a #define, > -DMAIN_VEX_SUBVERSION=0 or something? > > Even better would it be possible to put the version string in the define > itself? Something like -DVER_SUBVERSION=`svnversion` when building VEX > standalone and -DVEX_SUBERVSION=version in valgrind. > > There does seem little point in having this function in Valgrind if it's > return value is a hard-coded meaningless string, I'm not aware of what > other projects VEX works with so can't comment on the ABI issue there. And it's been removed now! :) Nick |