On 28 August 2015 at 06:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > ... you can already append
> > a custom string after the version string with --with-extra-version
> > in configure. Here is for example one I use for development:
> > GIT_CURRENT=`cd $PGSOURCE && git rev-parse --short HEAD`
> > ./configure --with-extra-version=-$GIT_CURRENT
>
> Yeah. To clarify my earlier comment: what Salesforce did[1] was
> basically to modify the configure script to do this automatically.
> That meant that even a heavily-hacked development build would still
> advertise itself as having an identifiable commit hash. I think that
> leads to at least as much confusion as value added.
>
> The only way that something like this can have any integrity is if the
> hash is added in an automated, hands-off build process that works only
> from clean git pulls. The approach Michael suggests works just fine
> as part of a build script that's used that way. But I doubt that it's
> wise to put it somewhere where the hash could end up in hand-modified
> builds.
Thanks for the quick reponses. Yes, using --with-extra-version as
Michael mentioned is clearly a better solution than running
version_stamp.pl . I didn't know about that option, and executing
version_stamp.pl has its drawbacks, for example introducing local
changes to the working copy during compilation. It was solely meant as a
local workaround to identify which commit it came from.
Oh well, at least I learned how the patch delivery process works here,
that's at least something. :)
Thanks to you both for the info,
Øyvind
