On 28 August 2015 at 06:17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
