On Tue, Nov 5, 2013 at 2:05 PM, Oskari Saarenmaa <os@ohmu.fi> wrote:
>> I can see some value in that kind of information, ie. knowing what
>> patches a binary was built with, but this would only solve the
>> problem for git checkouts. Even for a git checkout, the binaries
>> won't be automatically updated unless you run "configure" again,
>> which makes it pretty unreliable.
>>
>> -1 from me.
>
> I don't think we can solve the problem of finding local changes for all the
> things people may do, but I'd guess it's pretty common to build postgresql
> from a clean local git checkout and with this change at least some portion
> of users would get some extra information. To solve the "rerun configure"
> thing we could put git version in a new header file and have a makefile
> dependency on .git/index for regenerating that file when needed.
>
> We could also let users override the extra version with a command line
> argument for configure so distributions could put the distribution package
> version there, for example "9.3.1-2.fc20" on my Fedora system.
>
>> PS, the git command in the patch doesn't work with my version of git:
>>
>> $ git describe --tags --long --dirty HEAD
>> fatal: --dirty is incompatible with committishes
>> $ git --version
>> git version 1.8.4.rc3
>
> I initially used HEAD when looking at the git describe values, but then
> added --dirty which obviously doesn't make sense when describing a ref.
>
> Sorry about the broken patch, I was applying these changes manually from
> configure.in to configure because I didn't have the proper autoconf version
> installed (autoconf 2.63 doesn't seem to be available in many distributions
> anymore, maybe the required version could be upgraded at some point..)
>
> How about the patch below to fix the exact tag and --dirty issues?
A similar thing has been discussed a couple of months ago, and the
idea to add any git-related information in configure has been
rejected. You can have a look at the discussion here:
http://www.postgresql.org/message-id/3038.1374031659@sss.pgh.pa.us
As well as a potential solution here:
http://www.postgresql.org/message-id/c51433da5e804767724d60eea57f4178.squirrel@webmail.xs4all.nl
Regards,
--
Michael
