Re: [PATCH] use new global, "Version", rather than macro, VERSION

[Jim Meyering]

Eric Blake <address@hidden> 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' > address@hidden
>> +    printf 'char const *Version = "$(PACKAGE_VERSION)";\n' >> address@hidden
>> +    @chmod a-w address@hidden
>> +    mv address@hidden $@
>
> 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 ;-)