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
