-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Jim Meyering on 8/28/2008 5:54 AM: > This change makes ccache (http://ccache.samba.org/) more useful in > that cached .o files from one build are usually still useful after a > version number change. Before, due to the use of VERSION, the old .o > files would be useless and just pollute the cache. > > This first patch uses version-controlled files named > src/version.[ch]. The second change-set makes it so they > are generated, and hence not version-controlled. > > Comments or suggested improvements welcome.
This is EXACTLY the heart of the matter impacting the GNUmakefile discussion. In your second patch, why is version.h generated? In reality, only version.c needs to be generated, since it is the only file with varying contents. > * src/Makefile.am: Put it in a library that everyone links to. > (noinst_LIBRARIES, libver_a_SOURCES): Define. > (LDADD): Add libver.a. Is the library a necessity, or is version.o sufficient? > > +BUILT_SOURCES += version.c > +version.c: Makefile > + rm -f $@ > + printf '#include <config.h>\n' > [EMAIL PROTECTED] > + printf 'char const *Version = "$(PACKAGE_VERSION)";\n' >> [EMAIL > PROTECTED] > + @chmod a-w [EMAIL PROTECTED] > + mv [EMAIL PROTECTED] $@ Oops. This still doesn't solve the GNUmakefile debate. For this design to solve that issue, you need to use something other than PACKAGE_VERSION, so that you can guarantee that config.h is not polluted with version changes. Is it worth calling git-version-gen directly? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki2m5IACgkQ84KuGfSFAYD+eQCgl86tPwYzYUQ+tvW1IYADJJvy n/8AoL+xank/XFVWp76TwgyjoyxY9etR =iq/E -----END PGP SIGNATURE-----
