Hello Tom,
>> I've seen issues with a number of tools. The one I can remember most
>> clearly is check_postgres.pl . Nobody's going to argue that this is
>> pretty code, but last time I tested (9.4-era, admittedly) it exploded
>> messily with extra-version.
>
> FWIW, Salesforce tried to do something similar to Peter's example
> while I was there. It did not work as well as we'd hoped :-( because
> what got baked into the built executables was the latest git commit hash
> as of the time you'd last run configure, not what was current as of the
> latest "make". Not to mention that you might have built from an
> uncommitted state. We tried to find a fix for the former problem that
> didn't create lots of overhead, without much success.
My 0.02€:
For a research project we regenerate a header file with a string
containing the working copy status information,
// file version.h #define REV "<version-output>"
and there is a very small C file which is recompiled with a constant
string based on the version:
// version.c #include "version.h" const char * version = REV;
The make dependencies ensure that the header file is regenerated on each
build with a phony target, and the C file is thus recompiled and linked
into the executables on each build. It means that all executables are
linked on each rebuild, even if not necessary, though.
> No idea what to do about the latter.
"svnversion" adds a "M" for modified on the status. There is an option
with "git describe" to get something similar:
git describe --long --always --all --dirty
Also there is a need of a fall back if this fails, to get "<unknown
version>" instead.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers