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.
That'd be quite painful,
Hello Robert,
Mmph. I understand the desire to identify the exact commit used for a
build somehow, but something whose output depends on whether or not I
left a branch lying around locally doesn't seem that great.
Indeed, the branch/tag search might have a little strange behavior.
Probably
On Sat, Oct 14, 2017 at 4:47 AM, Robert Haas wrote:
> Mmph. I understand the desire to identify the exact commit used for a
> build somehow, but something whose output depends on whether or not I
> left a branch lying around locally doesn't seem that great.
Similarly to Peter, I prefer a minimum
On Thu, Oct 12, 2017 at 4:50 PM, Fabien COELHO wrote:
> "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
I tried this out a bit:
[rhaas pgsql]$ git describe --long --always --
Hi,
On 2017-10-12 22:50:47 +0200, Fabien COELHO wrote:
> 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 rebui
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
Craig Ringer writes:
> On 12 October 2017 at 06:46, Peter Eisentraut
> wrote:
>> I've been using
>> --with-extra-version=+git`date +%Y%m%d`"~"`git rev-parse --short HEAD`
>> for my local builds for some time, and I've not experienced any such
>> problems.
> I've seen issues with a number of tool
On 12 October 2017 at 06:46, Peter Eisentraut
wrote:
> I've been using
>
> --with-extra-version=+git`date +%Y%m%d`"~"`git rev-parse --short HEAD`
>
> for my local builds for some time, and I've not experienced any such
> problems.
Interesting.
I've seen issues with a number of tools. The one I
On 10/11/17 04:19, Craig Ringer wrote:
> On 11 October 2017 at 11:44, Jeremy Schneider
> wrote:
>> On Sun, Oct 1, 2017 at 8:10 AM, Tom Lane wrote:
>>>
>>> configure --with-extra-version=whateveryouwant
>>
>> I see that this build option has been around since 9.4; is anyone
>> using it to mark pa
On Wed, Oct 11, 2017 at 1:19 AM, Craig Ringer wrote:
> We started using it for BDR, but unfortunately too much software
> explodes spectacularly when you use it, due to simplistic/buggy
> version parsing.
Since 10.0 will break most of that software anyway, maybe this is a
good time to revisit the
On 11 October 2017 at 11:44, Jeremy Schneider wrote:
> On Sun, Oct 1, 2017 at 8:10 AM, Tom Lane wrote:
>>
>> configure --with-extra-version=whateveryouwant
>
> I see that this build option has been around since 9.4; is anyone
> using it to mark patched production builds? EnterpriseDB or
> 2ndQua
On Sun, Oct 1, 2017 at 8:10 AM, Tom Lane wrote:
>
> configure --with-extra-version=whateveryouwant
I see that this build option has been around since 9.4; is anyone
using it to mark patched production builds? EnterpriseDB or
2ndQuadrant? How about the cloud providers?
-Jeremy
--
http://about.
Hello,
Fabien COELHO writes:
I wanted to know which version it was, and "11devel" is kind of imprecise.
...
ISTM that extending the version name with the commit id and or date in
some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it.
configure --with-extra-version=whatever
Fabien COELHO writes:
> I wanted to know which version it was, and "11devel" is kind of imprecise.
> ...
> ISTM that extending the version name with the commit id and or date in
> some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it.
configure --with-extra-version=whateveryouw
Hello,
I use postgres "11devel" packages kindly distributed on
"apt.postgresql.org" and recompiled every few hours.
I wanted to know which version it was, and "11devel" is kind of imprecise.
Ok, there is a hint in the deb package name:
11~~devel~20170930.2214-1~87.git2632bcc.pgdg16.
15 matches
Mail list logo