On Tue, Nov 5, 2013 at 2:05 PM, Oskari Saarenmaa <o...@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.1374031...@sss.pgh.pa.us As well as a potential solution here: http://www.postgresql.org/message-id/c51433da5e804767724d60eea57f4178.squir...@webmail.xs4all.nl
Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
