Eric Blake <[EMAIL PROTECTED]> wrote: > 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.
I did that to keep the declaration and definition "close". It's not essential, but feels a little cleaner. >> * 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? Using version.o would be sufficient, but would require unmaintainable changes to coreutils' src/Makefile.am. Using a library seems like the easiest way to ensure each binary gets the new symbol without enumerating the dependency manually in src/Makefile.am. If someone can find a way to avoid the library with that constraint, I'd much prefer that. >> +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? For now, my aim was solely to avoid ccache waste. And as long as the compiled code doesn't *use* the changing symbols that's just fine. Of course, it'd be even better if config.h didn't have to change at all, but to get there, we'll have to change or override m4 macros that emit *VERSION definitions. One step at a time ;-) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
