pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedWindows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
37+ messages / 10 participants
[nested] [flat]
* Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 15:56 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 37+ messages in thread
From: Peter Eisentraut @ 2018-08-21 15:56 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; sandeep.thakkar@enterprisedb.com; +Cc: Thomas Munro <thomas.munro@enterprisedb.com>; Tom Lane <tgl@sss.pgh.pa.us>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 16/08/2018 15:00, Andres Freund wrote:
>> According to my research (completely untested in practice), you need
>> 2010 for mixed code and declarations and 2013 for named initialization
>> of structs.
>>
>> I wonder what raising the msvc requirement would imply for supporting
>> older Windows versions.
> One relevant tidbit is that afaict 2013 still allows *targeting* older
> versions of windows, down to XP and 2003, while requiring a newer
> platforms to run. See:
> https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-compatibility-vs
> I don't know if that's hard to do, but I strongly suspect that the
> existing installers already do that (otherwise supporting newer versions
> would likely require separate builds).
So, does anyone with Windows build experience want to comment on this?
The proposal is to desupport anything older than (probably) MSVC 2013,
or alternatively anything that cannot compile the attached test file.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
struct foo
{
int a;
int b;
};
struct foo f = {
.a = 1,
.b = 2,
};
int
bar()
{
int x;
x = 1;
int y;
y = 2;
for (int i = 0; i < 5; i++)
;
return 0;
}
Attachments:
[text/plain] test-c99.c (167B, ../../97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com/2-test-c99.c)
download | inline:
struct foo
{
int a;
int b;
};
struct foo f = {
.a = 1,
.b = 2,
};
int
bar()
{
int x;
x = 1;
int y;
y = 2;
for (int i = 0; i < 5; i++)
;
return 0;
}
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 17:29 Tom Lane <tgl@sss.pgh.pa.us>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 1 reply; 37+ messages in thread
From: Tom Lane @ 2018-08-21 17:29 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Andres Freund <andres@anarazel.de>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> So, does anyone with Windows build experience want to comment on this?
> The proposal is to desupport anything older than (probably) MSVC 2013,
> or alternatively anything that cannot compile the attached test file.
We've got a buildfarm handy that could answer the question.
Let's just stick a test function in there for a day and see
which animals fail.
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 17:31 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-21 17:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > So, does anyone with Windows build experience want to comment on this?
> > The proposal is to desupport anything older than (probably) MSVC 2013,
> > or alternatively anything that cannot compile the attached test file.
>
> We've got a buildfarm handy that could answer the question.
> Let's just stick a test function in there for a day and see
> which animals fail.
I think we pretty much know the answer already, anything before 2013
will fail. The question is more whether that's problematic for the
people building on windows. My theory, quoted by Peter upthread, is
that it shouldn't be problematic because 2013 can build binaries that
run on XP etc.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 17:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 3 replies; 37+ messages in thread
From: Tom Lane @ 2018-08-21 17:46 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Andres Freund <andres@anarazel.de> writes:
> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>> We've got a buildfarm handy that could answer the question.
>> Let's just stick a test function in there for a day and see
>> which animals fail.
> I think we pretty much know the answer already, anything before 2013
> will fail.
Do we know that for sure? I thought it was theoretical.
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 17:54 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-21 17:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
On 2018-08-21 13:46:10 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> >> We've got a buildfarm handy that could answer the question.
> >> Let's just stick a test function in there for a day and see
> >> which animals fail.
>
> > I think we pretty much know the answer already, anything before 2013
> > will fail.
>
> Do we know that for sure? I thought it was theoretical.
Pretty much. I'm on mobile data so I don't want to search too much, but
I've previously looked it up, and designated initializer support was
introduced in 2013. See e.g. the graph in
https://blogs.msdn.microsoft.com/somasegar/2013/06/28/c-conformance-roadmap/
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 18:03 Chapman Flack <chap@anastigmatix.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 37+ messages in thread
From: Chapman Flack @ 2018-08-21 18:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 08/21/2018 01:46 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>>> We've got a buildfarm handy that could answer the question.
>>> Let's just stick a test function in there for a day and see
>>> which animals fail.
>
>> I think we pretty much know the answer already, anything before 2013
>> will fail.
>
> Do we know that for sure? I thought it was theoretical.
I thought I remembered a message where it had been looked up in docs,
but I think the one I was remembering was Peter's "According to my
research (completely untested in practice), you need 2010 for
mixed code and declarations and 2013 for named initialization
of structs." [1] which didn't quite actually say it was documented.
-Chap
[1]
https://www.postgresql.org/message-id/ef986aa7-c7ca-ec34-19d9-fef38716b109%402ndquadrant.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 18:06 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 2 replies; 37+ messages in thread
From: Andrew Dunstan @ 2018-08-21 18:06 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 08/21/2018 01:31 PM, Andres Freund wrote:
> Hi,
>
> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> So, does anyone with Windows build experience want to comment on this?
>>> The proposal is to desupport anything older than (probably) MSVC 2013,
>>> or alternatively anything that cannot compile the attached test file.
>> We've got a buildfarm handy that could answer the question.
>> Let's just stick a test function in there for a day and see
>> which animals fail.
> I think we pretty much know the answer already, anything before 2013
> will fail. The question is more whether that's problematic for the
> people building on windows. My theory, quoted by Peter upthread, is
> that it shouldn't be problematic because 2013 can build binaries that
> run on XP etc.
>
XP at least is essentially a dead platform for us. My animals are not
able to build anything after release 10.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 18:09 Joshua D. Drake <jd@commandprompt.com>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
1 sibling, 1 reply; 37+ messages in thread
From: Joshua D. Drake @ 2018-08-21 18:09 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
>
>
>
> XP at least is essentially a dead platform for us. My animals are not
> able to build anything after release 10.
I wouldn't think XP should even be on our list anymore. Microsoft hasn't
supported it in 4 years.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
*** A fault and talent of mine is to tell it exactly how it is. ***
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
***** Unless otherwise stated, opinions are my own. *****
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 18:10 Andres Freund <andres@anarazel.de>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
1 sibling, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-21 18:10 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2018-08-21 14:06:18 -0400, Andrew Dunstan wrote:
>
>
> On 08/21/2018 01:31 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
> > > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > > > So, does anyone with Windows build experience want to comment on this?
> > > > The proposal is to desupport anything older than (probably) MSVC 2013,
> > > > or alternatively anything that cannot compile the attached test file.
> > > We've got a buildfarm handy that could answer the question.
> > > Let's just stick a test function in there for a day and see
> > > which animals fail.
> > I think we pretty much know the answer already, anything before 2013
> > will fail. The question is more whether that's problematic for the
> > people building on windows. My theory, quoted by Peter upthread, is
> > that it shouldn't be problematic because 2013 can build binaries that
> > run on XP etc.
> XP at least is essentially a dead platform for us. My animals are not able
> to build anything after release 10.
I'm perfectly fine with that, FWIW. It's out of extended support for
several years now. But my point was that you can newer versions of MSVC
to build things that run on XP (and more relevantly 2008, vista, 7 etc).
No idea if we'd need to change anything in our build infra for that.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 20:49 Andres Freund <andres@anarazel.de>
parent: Joshua D. Drake <jd@commandprompt.com>
0 siblings, 1 reply; 37+ messages in thread
From: Andres Freund @ 2018-08-21 20:49 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> >
> >
> >
> > XP at least is essentially a dead platform for us. My animals are not
> > able to build anything after release 10.
>
> I wouldn't think XP should even be on our list anymore. Microsoft hasn't
> supported it in 4 years.
XP isn't the only thing relevant here, vista and 2008 R1 are in the same
class.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 21:58 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 37+ messages in thread
From: Andrew Dunstan @ 2018-08-21 21:58 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; Joshua D. Drake <jd@commandprompt.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 08/21/2018 04:49 PM, Andres Freund wrote:
> On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
>> On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
>>>
>>>
>>> XP at least is essentially a dead platform for us. My animals are not
>>> able to build anything after release 10.
>> I wouldn't think XP should even be on our list anymore. Microsoft hasn't
>> supported it in 4 years.
> XP isn't the only thing relevant here, vista and 2008 R1 are in the same
> class.
>
I do have a machine in my laptop graveyard with Vista. The only WS2008
instace I have available is R2 and AWS doesn't seem to have any AMIs for R1.
Honestly, I don't think these matter terribly much. Anyone building now
is not likely to be targeting them.
Of the buildfarm animals, dory looks OK, hamerkop, bowerbird and thrips
look not ok, and whelk and woodlouse look borderline.
I'm perfectly prepared to upgrade bowerbird if necessary.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-21 23:29 Andres Freund <andres@anarazel.de>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 37+ messages in thread
From: Andres Freund @ 2018-08-21 23:29 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; sandeep.thakkar@enterprisedb.com, Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:
>
>
> On 08/21/2018 04:49 PM, Andres Freund wrote:
> > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> > > >
> > > >
> > > > XP at least is essentially a dead platform for us. My animals are not
> > > > able to build anything after release 10.
> > > I wouldn't think XP should even be on our list anymore. Microsoft hasn't
> > > supported it in 4 years.
> > XP isn't the only thing relevant here, vista and 2008 R1 are in the same
> > class.
> >
>
>
> I do have a machine in my laptop graveyard with Vista. The only WS2008
> instace I have available is R2 and AWS doesn't seem to have any AMIs for R1.
>
> Honestly, I don't think these matter terribly much. Anyone building now is
> not likely to be targeting them.
I agree, I think we should just decree that the minimum is MSVC 2013 and
that people building 12 need to deal with that. I would personally
*additionally* would say that we officially don't support *running* (not
compiling) on XP, 2003, 2008R1 and Vista (all unsupported by MS) - but
that's a somewhat orthogonal decision.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 10:28 Amit Kapila <amit.kapila16@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 37+ messages in thread
From: Amit Kapila @ 2018-08-22 10:28 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Aug 21, 2018 at 11:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-08-21 13:29:20 -0400, Tom Lane wrote:
>>> We've got a buildfarm handy that could answer the question.
>>> Let's just stick a test function in there for a day and see
>>> which animals fail.
>
>> I think we pretty much know the answer already, anything before 2013
>> will fail.
>
> Do we know that for sure? I thought it was theoretical.
>
I have MSVC 2010 on my Windows 7 VM where I have tried the C99
constructs provided by Peter E. and below are my findings:
Tried compiling below function in one of the .c files in the src/backend
-----------------------------------------------------------------------------------------------
int
bar()
{
int x;
x = 1;
int y;
y = 2;
for (int i = 0; i < 5; i++)
;
return 0;
}
error C2143: syntax error : missing ';' before 'type'
error C2065: 'y' : undeclared identifier
error C2143: syntax error : missing ';' before 'type'
error C2143: syntax error : missing ';' before 'type'
error C2143: syntax error : missing ')' before 'type'
error C2143: syntax error : missing ';' before 'type'
error C2065: 'i' : undeclared identifier
warning C4552: '<' : operator has no effect; expected operator with side-effect
error C2065: 'i' : undeclared identifier
error C2059: syntax error : ')'
Tried compiling below struct in one of the .c files in the src/backend
-----------------------------------------------------------------------------------------------
struct foo
{
int a;
int b;
};
struct foo f = {
.a = 1,
.b = 2
};
error C2059: syntax error : '.'
I have also tried compiling above in standalone console application
project in MSVC 2010 and able to compile the function successfully,
but struct is giving the same error as above. So, it seems to me that
it won't work on <= MSVC 2010. I am personally okay with upgrading my
Windows VM.
I have found a couple of links which suggest that MSVC 2015 has a good
amount of conformance with C99 [1]. It seems MSVC 2013 also has
decent support for C99 [2], but I am not able to verify if the
constructs shared by Peter E can be compiled on it.
[1] https://social.msdn.microsoft.com/Forums/en-US/fa17bcdd-7165-4645-a676-ef3797b95918/details-on-c99-s...
[2] https://blogs.msdn.microsoft.com/vcblog/2013/07/19/c99-library-support-in-visual-studio-2013/
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 11:47 Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 37+ messages in thread
From: Sandeep Thakkar @ 2018-08-22 11:47 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Aug 22, 2018 at 4:59 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-08-21 17:58:00 -0400, Andrew Dunstan wrote:
> >
> >
> > On 08/21/2018 04:49 PM, Andres Freund wrote:
> > > On 2018-08-21 11:09:15 -0700, Joshua D. Drake wrote:
> > > > On 08/21/2018 11:06 AM, Andrew Dunstan wrote:
> > > > >
> > > > >
> > > > > XP at least is essentially a dead platform for us. My animals are
> not
> > > > > able to build anything after release 10.
> > > > I wouldn't think XP should even be on our list anymore. Microsoft
> hasn't
> > > > supported it in 4 years.
> > > XP isn't the only thing relevant here, vista and 2008 R1 are in the
> same
> > > class.
> > >
> >
> >
> > I do have a machine in my laptop graveyard with Vista. The only WS2008
> > instace I have available is R2 and AWS doesn't seem to have any AMIs for
> R1.
> >
> > Honestly, I don't think these matter terribly much. Anyone building now
> is
> > not likely to be targeting them.
>
> I agree, I think we should just decree that the minimum is MSVC 2013 and
> that people building 12 need to deal with that. I would personally
> *additionally* would say that we officially don't support *running* (not
> compiling) on XP, 2003, 2008R1 and Vista (all unsupported by MS) - but
> that's a somewhat orthogonal decision.
>
> We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.
For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
2013. For v11, we use 2017.
> Greetings,
>
> Andres Freund
>
--
Sandeep Thakkar
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 12:02 Andres Freund <andres@anarazel.de>
parent: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
0 siblings, 3 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-22 12:02 UTC (permalink / raw)
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:
> > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012 R2.
> For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
> 2013. For v11, we use 2017.
Sndeep: Thanks for the information. Did you ever encounter problems (at
build or during runtime) with using those binaries on older platforms?
Everyone: Given the fact that all the people building windows packages
currently use a new enough stack by a fair margin, I think we should
conclude that there's no obstacle on the windows side of things.
If we agree on that, I'm going to propose a patch that includes:
- relevant cleanups to configure
- adapts sources.sgml to refer to C99 instead of C89
- add some trivial conversions to for(int i;;) and struct initializers,
so the relevant old animals fail
- adds a configure check to enable errors with vla usage (-Werror=vla)
Questions:
- do we want to make declarations at arbitrary points errors? It's
already a warning currently.
- other new restrictions that we want to introduce at the same time?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 12:22 Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
parent: Andres Freund <andres@anarazel.de>
2 siblings, 0 replies; 37+ messages in thread
From: Sandeep Thakkar @ 2018-08-22 12:22 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Wed, Aug 22, 2018 at 5:32 PM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> On 2018-08-22 17:17:27 +0530, Sandeep Thakkar wrote:
> > > We build windows binaries (>=9.3) on Windows 7 and Windows Server 2012
> R2.
> > For 9.3, the Visual Studio version is 2010 and for 9.4 and v10, we use
> > 2013. For v11, we use 2017.
>
> Sndeep: Thanks for the information. Did you ever encounter problems (at
> build or during runtime) with using those binaries on older platforms?
>
> IIRC when the binaries were built with VC++ 2013 on 9.4, we had problems
running them on XP and hence we had used "/p:PlatformToolset=v120_xp"
option to msbuild during build time. From v10, we stopped using that
toolset and instead used the default one i.e v120
> Everyone: Given the fact that all the people building windows packages
> currently use a new enough stack by a fair margin, I think we should
> conclude that there's no obstacle on the windows side of things.
>
>
> If we agree on that, I'm going to propose a patch that includes:
> - relevant cleanups to configure
> - adapts sources.sgml to refer to C99 instead of C89
> - add some trivial conversions to for(int i;;) and struct initializers,
> so the relevant old animals fail
> - adds a configure check to enable errors with vla usage (-Werror=vla)
>
> Questions:
>
> - do we want to make declarations at arbitrary points errors? It's
> already a warning currently.
> - other new restrictions that we want to introduce at the same time?
>
> Greetings,
>
> Andres Freund
>
--
Sandeep Thakkar
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 14:56 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
2 siblings, 2 replies; 37+ messages in thread
From: Peter Eisentraut @ 2018-08-22 14:56 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 22/08/2018 14:02, Andres Freund wrote:
> If we agree on that, I'm going to propose a patch that includes:
> - relevant cleanups to configure
> - adapts sources.sgml to refer to C99 instead of C89
> - add some trivial conversions to for(int i;;) and struct initializers,
> so the relevant old animals fail
> - adds a configure check to enable errors with vla usage (-Werror=vla)
sounds good
> - do we want to make declarations at arbitrary points errors? It's
> already a warning currently.
While there are legitimate criticisms, it's a standard feature in C,
C++, and many other languages, so I don't see what we'd gain by fighting it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 15:01 Andres Freund <andres@anarazel.de>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-22 15:01 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
On 2018-08-22 16:56:15 +0200, Peter Eisentraut wrote:
> On 22/08/2018 14:02, Andres Freund wrote:
> > - do we want to make declarations at arbitrary points errors? It's
> > already a warning currently.
>
> While there are legitimate criticisms, it's a standard feature in C,
> C++, and many other languages, so I don't see what we'd gain by fighting it.
I personally don't really care - for C there's really not much of a
difference (contrast to C++ with RAII). But Robert and Tom both said
this would be an issue with moving to C99 for them. I don't want to hold
up making progress here by fighting over this issue.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-22 16:56 David Steele <david@pgmasters.net>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
1 sibling, 0 replies; 37+ messages in thread
From: David Steele @ 2018-08-22 16:56 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Andres Freund <andres@anarazel.de>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 8/22/18 10:56 AM, Peter Eisentraut wrote:
> On 22/08/2018 14:02, Andres Freund wrote:
>> If we agree on that, I'm going to propose a patch that includes:
>> - relevant cleanups to configure
>> - adapts sources.sgml to refer to C99 instead of C89
>> - add some trivial conversions to for(int i;;) and struct initializers,
>> so the relevant old animals fail
>> - adds a configure check to enable errors with vla usage (-Werror=vla)
>
> sounds good
Sounds good to me.
>
>> - do we want to make declarations at arbitrary points errors? It's
>> already a warning currently.
>
> While there are legitimate criticisms, it's a standard feature in C,
> C++, and many other languages, so I don't see what we'd gain by fighting it.
+1.=
--
-David
david@pgmasters.net
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-23 00:09 Andres Freund <andres@anarazel.de>
parent: Andres Freund <andres@anarazel.de>
2 siblings, 2 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-23 00:09 UTC (permalink / raw)
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Hi,
On 2018-08-22 05:02:11 -0700, Andres Freund wrote:
> If we agree on that, I'm going to propose a patch that includes:
> - relevant cleanups to configure
> - adapts sources.sgml to refer to C99 instead of C89
> - add some trivial conversions to for(int i;;) and struct initializers,
> so the relevant old animals fail
> - adds a configure check to enable errors with vla usage (-Werror=vla)
>
> Questions:
>
> - do we want to make declarations at arbitrary points errors? It's
> already a warning currently.
> - other new restrictions that we want to introduce at the same time?
Attached is a version doing so. Turns out ripping < msvc 2010 support
allows us to get rid of a fair bit of code. Using appveyor I tested
that I didn't bungle things too badly. But I don't really know what I'm
doing in that area, Andrew or Craig, your input would be appreciated.
I tried to update sources.sgml to reflect my understanding of the subset
of C99 we're going to use. I'd rather start more restrictive and then
argue about relaxing things separately.
There's a few further potential cleanups due to relying on c99:
- Use __func__ unconditionally, rather than having configure test for it
- Use inline unconditionally, rather than having configure test for it
- Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
AC_TYPE_LONG_LONG_INT, we can rely on them being present.
- probably more in that vein
I'd rather do these separately lateron, in case one of them causes
trouble on some animals.
There's some potential ones I think we should *not* do:
- remove AC_C_FLEXIBLE_ARRAY_MEMBER, and rely on it unconditionally.
I'm disinclined to do this, because C++ IIRC doesn't support it in any
version, and I don't want to make Peter's life unnecessarily hard.
- remove AC_C_RESTRICT check, rely on it unconditionally: MSVC still
spells this differently.
Greetings,
Andres Freund
Attachments:
[text/x-diff] v1-0001-Require-C99-and-thus-MSCV-2013-upwards.patch (8.0K, ../../20180823000905.fjthfohmczss4fiw@alap3.anarazel.de/2-v1-0001-Require-C99-and-thus-MSCV-2013-upwards.patch)
download | inline diff:
From c579be2ae7a020d6005d84a5b6f24872ba8b1b05 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 15:10:23 -0700
Subject: [PATCH v1 1/4] Require C99 (and thus MSCV 2013 upwards).
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
configure | 49 ++++++++++++++++++++++++++++++++
configure.in | 10 +++++++
doc/src/sgml/sources.sgml | 33 ++++++++++++++-------
src/tools/msvc/MSBuildProject.pm | 2 +-
src/tools/msvc/README | 6 ++--
src/tools/msvc/build.pl | 6 +---
6 files changed, 86 insertions(+), 20 deletions(-)
diff --git a/configure b/configure
index 836d68dad37..dd439ddd2f6 100755
--- a/configure
+++ b/configure
@@ -4602,6 +4602,13 @@ if test "x$ac_cv_prog_cc_c99" != xno; then :
fi
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+ as_fn_error $? "C compiler \"$CC\" does not support C99" "$LINENO" 5
+fi
+
ac_ext=cpp
ac_cpp='$CXXCPP $CPPFLAGS'
ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -5361,6 +5368,48 @@ fi
# -Wdeclaration-after-statement isn't applicable for C++
+ # Really don't want VLAs to be used in our dialect of C
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Werror=vla, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -Werror=vla, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__Werror_vla+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -Werror=vla"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__Werror_vla=yes
+else
+ pgac_cv_prog_CC_cflags__Werror_vla=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Werror_vla" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__Werror_vla" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__Werror_vla" = x"yes"; then
+ CFLAGS="${CFLAGS} -Werror=vla"
+fi
+
+
+ # -Wvla is not applicable for C++
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wendif-labels, for CFLAGS" >&5
$as_echo_n "checking whether ${CC} supports -Wendif-labels, for CFLAGS... " >&6; }
diff --git a/configure.in b/configure.in
index 6e141064e5c..5869ab7c5bc 100644
--- a/configure.in
+++ b/configure.in
@@ -359,6 +359,13 @@ esac
AC_PROG_CC([$pgac_cc_list])
AC_PROG_CC_C99()
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+ AC_MSG_ERROR([C compiler "$CC" does not support C99])
+fi
+
AC_PROG_CXX([$pgac_cxx_list])
# Check if it's Intel's compiler, which (usually) pretends to be gcc,
@@ -477,6 +484,9 @@ if test "$GCC" = yes -a "$ICC" = no; then
# These work in some but not all gcc versions
PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])
# -Wdeclaration-after-statement isn't applicable for C++
+ # Really don't want VLAs to be used in our dialect of C
+ PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
+ # -Wvla is not applicable for C++
PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index e53ee1dc6ad..419f753c7bc 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -867,19 +867,30 @@ BETTER: unrecognized node type: 42
<title>C Standard</title>
<para>
Code in <productname>PostgreSQL</productname> should only rely on language
- features available in the C89 standard. That means a conforming
- C89 compiler has to be able to compile postgres, at least aside
- from a few platform dependent pieces. Features from later
- revision of the C standard or compiler specific features can be
- used, if a fallback is provided.
+ features available in the C99 standard. That means a conforming
+ C99 compiler has to be able to compile postgres, at least aside
+ from a few platform dependent pieces.
</para>
<para>
- For example <literal>static inline</literal> and
- <literal>_StaticAssert()</literal> are currently used, even
- though they are from newer revisions of the C standard. If not
- available we respectively fall back to defining the functions
- without inline, and to using a C89 compatible replacement that
- performs the same checks, but emits rather cryptic messages.
+ A few features included in the C99 standard are, at this time, not be
+ permitted to be used in core <productname>PostgreSQL</productname>
+ code. This currently includes variable length arrays, intermingled
+ declarations and code, <literal>//</literal> comments, universal
+ character names. Reasons for that include portability and historical
+ practices.
+ </para>
+ <para>
+ Features from later revision of the C standard or compiler specific
+ features can be used, if a fallback is provided.
+ </para>
+ <para>
+ For example <literal>_StaticAssert()</literal> and
+ <literal>__builtin_constant_p</literal> are currently used, even though
+ they are from newer revisions of the C standard and a
+ <productname>GCC</productname> extension respectively. If not available
+ we respectively fall back to using a C99 compatible replacement that
+ performs the same checks, but emits rather cryptic messages and do not
+ use <literal>__builtin_constant_p</literal>.
</para>
</simplesect>
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index 47252533a1b..dd6a610e5b2 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -1,7 +1,7 @@
package MSBuildProject;
#
-# Package that encapsulates a MSBuild project file (Visual C++ 2010 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
#
# src/tools/msvc/MSBuildProject.pm
#
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index bfa98045f22..2827d76b2d1 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -67,7 +67,7 @@ Install.pm module containing the install logic
Mkvcbuild.pm module containing the code to generate the Visual
Studio build (project/solution) files
MSBuildProject.pm module containing the code to generate MSBuild based
- project files (Visual Studio 2010 or greater)
+ project files (Visual Studio 2013 or greater)
Project.pm module containing the common code to generate the
Visual Studio project files. Also provides the
common interface of all project file generators
@@ -99,5 +99,5 @@ VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Projec
from MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
-The final step of starting the appropriate build program (msbuild or vcbuild)
-is performed in build.pl again.
+The final step of starting the appropriate build program (msbuild) is
+performed in build.pl again.
diff --git a/src/tools/msvc/build.pl b/src/tools/msvc/build.pl
index 9a234d1cc25..35649fe5a24 100644
--- a/src/tools/msvc/build.pl
+++ b/src/tools/msvc/build.pl
@@ -53,16 +53,12 @@ elsif (uc($ARGV[0]) ne "RELEASE")
# ... and do it
-if ($buildwhat and $vcver >= 10.00)
+if ($buildwhat)
{
system(
"msbuild $buildwhat.vcxproj /verbosity:normal $msbflags /p:Configuration=$bconf"
);
}
-elsif ($buildwhat)
-{
- system("vcbuild $msbflags $buildwhat.vcproj $bconf");
-}
else
{
system(
--
2.18.0.rc2.dirty
[text/x-diff] v1-0002-Remove-test-for-VA_ARGS-implied-by-C99.patch (26.1K, ../../20180823000905.fjthfohmczss4fiw@alap3.anarazel.de/3-v1-0002-Remove-test-for-VA_ARGS-implied-by-C99.patch)
download | inline diff:
From 5f6bedf514c9fa30ce5f3f3e88e95f77a2bde91c Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:04:47 -0700
Subject: [PATCH v1 2/4] Remove test for VA_ARGS, implied by C99.
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
config/c-compiler.m4 | 19 --
configure | 34 +---
configure.in | 1 -
doc/src/sgml/install-windows.sgml | 26 +--
src/include/pg_config.h.in | 3 -
src/include/pg_config.h.win32 | 3 -
src/include/utils/elog.h | 8 +-
src/pl/plpython/plpy_elog.h | 4 -
src/tools/msvc/MSBuildProject.pm | 76 +-------
src/tools/msvc/README | 12 +-
src/tools/msvc/Solution.pm | 102 ----------
src/tools/msvc/VCBuildProject.pm | 309 ------------------------------
src/tools/msvc/VSObjectFactory.pm | 37 +---
13 files changed, 27 insertions(+), 607 deletions(-)
delete mode 100644 src/tools/msvc/VCBuildProject.pm
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 67675a31bb6..eedaf12d69c 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -415,25 +415,6 @@ fi])# PGAC_C_COMPUTED_GOTO
-# PGAC_C_VA_ARGS
-# --------------
-# Check if the C compiler understands C99-style variadic macros,
-# and define HAVE__VA_ARGS if so.
-AC_DEFUN([PGAC_C_VA_ARGS],
-[AC_CACHE_CHECK(for __VA_ARGS__, pgac_cv__va_args,
-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <stdio.h>],
-[#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-])],
-[pgac_cv__va_args=yes],
-[pgac_cv__va_args=no])])
-if test x"$pgac_cv__va_args" = xyes ; then
-AC_DEFINE(HAVE__VA_ARGS, 1,
- [Define to 1 if your compiler understands __VA_ARGS__ in macros.])
-fi])# PGAC_C_VA_ARGS
-
-
-
# PGAC_PROG_VARCC_VARFLAGS_OPT
# -----------------------
# Given a compiler, variable name and a string, check if the compiler
diff --git a/configure b/configure
index dd439ddd2f6..af090ffb08f 100755
--- a/configure
+++ b/configure
@@ -13962,38 +13962,6 @@ if test x"$pgac_cv_computed_goto" = xyes ; then
$as_echo "#define HAVE_COMPUTED_GOTO 1" >>confdefs.h
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __VA_ARGS__" >&5
-$as_echo_n "checking for __VA_ARGS__... " >&6; }
-if ${pgac_cv__va_args+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-#include <stdio.h>
-int
-main ()
-{
-#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
- pgac_cv__va_args=yes
-else
- pgac_cv__va_args=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__va_args" >&5
-$as_echo "$pgac_cv__va_args" >&6; }
-if test x"$pgac_cv__va_args" = xyes ; then
-
-$as_echo "#define HAVE__VA_ARGS 1" >>confdefs.h
-
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether struct tm is in sys/time.h or time.h" >&5
$as_echo_n "checking whether struct tm is in sys/time.h or time.h... " >&6; }
@@ -19635,7 +19603,7 @@ PostgreSQL config.status 12devel
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
-Copyright (C) 2012 Free Software Foundation, Inc.
+Copyright (C) Free Software Foundation, Inc.
This config.status script is free software; the Free Software Foundation
gives unlimited permission to copy, distribute and modify it."
diff --git a/configure.in b/configure.in
index 5869ab7c5bc..3280afa0dab 100644
--- a/configure.in
+++ b/configure.in
@@ -1434,7 +1434,6 @@ PGAC_C_BUILTIN_BSWAP64
PGAC_C_BUILTIN_CONSTANT_P
PGAC_C_BUILTIN_UNREACHABLE
PGAC_C_COMPUTED_GOTO
-PGAC_C_VA_ARGS
PGAC_STRUCT_TIMEZONE
PGAC_UNION_SEMUN
PGAC_STRUCT_SOCKADDR_UN
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 9597bc35a14..22a2ffd55ee 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
Microsoft tools is to install <productname>Visual Studio Express 2017
for Windows Desktop</productname> and use the included
compiler. It is also possible to build with the full
- <productname>Microsoft Visual C++ 2005 to 2017</productname>.
+ <productname>Microsoft Visual C++ 2013 to 2017</productname>.
In some cases that requires the installation of the
<productname>Windows SDK</productname> in addition to the compiler.
</para>
@@ -77,20 +77,24 @@
<para>
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
32-bit PostgreSQL builds are possible with
- <productname>Visual Studio 2005</productname> to
+ <productname>Visual Studio 2013</productname> to
<productname>Visual Studio 2017</productname> (including Express editions),
as well as standalone Windows SDK releases 6.0 to 8.1.
64-bit PostgreSQL builds are supported with
<productname>Microsoft Windows SDK</productname> version 6.0a to 8.1 or
- <productname>Visual Studio 2008</productname> and above. Compilation
- is supported down to <productname>Windows XP</productname> and
- <productname>Windows Server 2003</productname> when building with
- <productname>Visual Studio 2005</productname> to
- <productname>Visual Studio 2013</productname>. Building with
- <productname>Visual Studio 2015</productname> is supported down to
- <productname>Windows Vista</productname> and <productname>Windows Server 2008</productname>.
- Building with <productname>Visual Studio 2017</productname> is supported
- down to <productname>Windows 7 SP1</productname> and <productname>Windows Server 2008 R2 SP1</productname>.
+ <productname>Visual Studio 2013</productname> and above. Compilation
+ is supported down to <productname>Windows 7</productname> and
+ <productname>Windows Server 2008 R2 SP1</productname> when building with
+ <productname>Visual Studio 2013</productname> to
+ <productname>Visual Studio 2017</productname>.
+ <!--
+ For 2013 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
+ For 2015 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
+ For 2017 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
+ -->
</para>
<para>
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 827574ee40d..37649d77d67 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -754,9 +754,6 @@
/* Define to 1 if your compiler understands _Static_assert. */
#undef HAVE__STATIC_ASSERT
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#undef HAVE__VA_ARGS
-
/* Define to 1 if you have the `__strtoll' function. */
#undef HAVE___STRTOLL
diff --git a/src/include/pg_config.h.win32 b/src/include/pg_config.h.win32
index 46ce49def2f..4e2bd3c1352 100644
--- a/src/include/pg_config.h.win32
+++ b/src/include/pg_config.h.win32
@@ -597,9 +597,6 @@
/* Define to 1 if your compiler understands _Static_assert. */
/* #undef HAVE__STATIC_ASSERT */
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#define HAVE__VA_ARGS 1
-
/* Define to the appropriate printf length modifier for 64-bit ints. */
#define INT64_MODIFIER "ll"
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 4350b120aab..33c6b53e278 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -207,9 +207,8 @@ extern int getinternalerrposition(void);
* elog(ERROR, "portal \"%s\" not found", stmt->portalname);
*----------
*/
-#ifdef HAVE__VA_ARGS
/*
- * If we have variadic macros, we can give the compiler a hint about the
+ * Using variadic macros, we can give the compiler a hint about the
* call not returning when elevel >= ERROR. See comments for ereport().
* Note that historically elog() has called elog_start (which saves errno)
* before evaluating "elevel", so we preserve that behavior here.
@@ -236,11 +235,6 @@ extern int getinternalerrposition(void);
} \
} while(0)
#endif /* HAVE__BUILTIN_CONSTANT_P */
-#else /* !HAVE__VA_ARGS */
-#define elog \
- elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), \
- elog_finish
-#endif /* HAVE__VA_ARGS */
extern void elog_start(const char *filename, int lineno, const char *funcname);
extern void elog_finish(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
diff --git a/src/pl/plpython/plpy_elog.h b/src/pl/plpython/plpy_elog.h
index e4b30c3cca1..b56ac412476 100644
--- a/src/pl/plpython/plpy_elog.h
+++ b/src/pl/plpython/plpy_elog.h
@@ -15,7 +15,6 @@ extern PyObject *PLy_exc_spi_error;
*
* See comments at elog() about the compiler hinting.
*/
-#ifdef HAVE__VA_ARGS
#ifdef HAVE__BUILTIN_CONSTANT_P
#define PLy_elog(elevel, ...) \
do { \
@@ -32,9 +31,6 @@ extern PyObject *PLy_exc_spi_error;
pg_unreachable(); \
} while(0)
#endif /* HAVE__BUILTIN_CONSTANT_P */
-#else /* !HAVE__VA_ARGS */
-#define PLy_elog PLy_elog_impl
-#endif /* HAVE__VA_ARGS */
extern void PLy_elog_impl(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index dd6a610e5b2..149213378cf 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -257,6 +257,7 @@ sub WriteConfigurationPropertyGroup
<UseOfMfc>false</UseOfMfc>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
+ <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
</PropertyGroup>
EOF
return;
@@ -391,75 +392,6 @@ EOF
return;
}
-package VC2010Project;
-
-#
-# Package that encapsulates a Visual C++ 2010 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '10.00';
-
- return $self;
-}
-
-package VC2012Project;
-
-#
-# Package that encapsulates a Visual C++ 2012 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '11.00';
- $self->{PlatformToolset} = 'v110';
-
- return $self;
-}
-
-# This override adds the <PlatformToolset> element
-# to the PropertyGroup labeled "Configuration"
-sub WriteConfigurationPropertyGroup
-{
- my ($self, $f, $cfgname, $p) = @_;
- my $cfgtype =
- ($self->{type} eq "exe")
- ? 'Application'
- : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary');
-
- print $f <<EOF;
- <PropertyGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'" Label="Configuration">
- <ConfigurationType>$cfgtype</ConfigurationType>
- <UseOfMfc>false</UseOfMfc>
- <CharacterSet>MultiByte</CharacterSet>
- <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
- <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
- </PropertyGroup>
-EOF
- return;
-}
-
package VC2013Project;
#
@@ -468,7 +400,7 @@ package VC2013Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
@@ -493,7 +425,7 @@ package VC2015Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
@@ -518,7 +450,7 @@ package VC2017Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index 2827d76b2d1..4ab81d3402f 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
==========
This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2005 - 2017. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2017. This builds the whole backend, not just
the libpq frontend library. For more information, see the documentation
chapter "Installation on Windows" and the description below.
@@ -73,8 +73,6 @@ Project.pm module containing the common code to generate the
common interface of all project file generators
Solution.pm module containing the code to generate the Visual
Studio solution files.
-VCBuildProject.pm module containing the code to generate VCBuild based
- project files (Visual Studio 2005/2008)
VSObjectFactory.pm factory module providing the code to create the
appropriate project/solution files for the current
environment
@@ -90,13 +88,11 @@ config_default.pl to create the configuration arguments.
These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either a VS2005Solution,
-a VS2008Solution, a VS2010Solution or a VS2012Solution or a VS2013Solution,
+implementing the Solution interface (this could be either a VS2013Solution,
or a VS2015Solution or a VS2017Solution, all in Solution.pm, depending on
the user's build environment) and adding objects implementing the corresponding
-Project interface (VC2005Project or VC2008Project from VCBuildProject.pm or
-VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Project
-from MSBuildProject.pm) to it.
+Project interface (VC2013Project or VC2015Project or VC2017Project from
+MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
The final step of starting the appropriate build program (msbuild) is
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 78db247b291..7d7ce8b0312 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -760,108 +760,6 @@ sub GetFakeConfigure
return $cfg;
}
-package VS2005Solution;
-
-#
-# Package that encapsulates a Visual Studio 2005 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '9.00';
- $self->{vcver} = '8.00';
- $self->{visualStudioName} = 'Visual Studio 2005';
-
- return $self;
-}
-
-package VS2008Solution;
-
-#
-# Package that encapsulates a Visual Studio 2008 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '10.00';
- $self->{vcver} = '9.00';
- $self->{visualStudioName} = 'Visual Studio 2008';
-
- return $self;
-}
-
-package VS2010Solution;
-
-#
-# Package that encapsulates a Visual Studio 2010 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '11.00';
- $self->{vcver} = '10.00';
- $self->{visualStudioName} = 'Visual Studio 2010';
-
- return $self;
-}
-
-package VS2012Solution;
-
-#
-# Package that encapsulates a Visual Studio 2012 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '12.00';
- $self->{vcver} = '11.00';
- $self->{visualStudioName} = 'Visual Studio 2012';
-
- return $self;
-}
-
package VS2013Solution;
#
diff --git a/src/tools/msvc/VCBuildProject.pm b/src/tools/msvc/VCBuildProject.pm
deleted file mode 100644
index 6cdf822a637..00000000000
--- a/src/tools/msvc/VCBuildProject.pm
+++ /dev/null
@@ -1,309 +0,0 @@
-package VCBuildProject;
-
-#
-# Package that encapsulates a VCBuild (Visual C++ 2005/2008) project file
-#
-# src/tools/msvc/VCBuildProject.pm
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Project);
-
-no warnings qw(redefine); ## no critic
-
-sub _new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{filenameExtension} = '.vcproj';
-
- return $self;
-}
-
-sub WriteHeader
-{
- my ($self, $f) = @_;
-
- print $f <<EOF;
-<?xml version="1.0" encoding="Windows-1252"?>
-<VisualStudioProject ProjectType="Visual C++" Version="$self->{vcver}" Name="$self->{name}" ProjectGUID="$self->{guid}">
- <Platforms><Platform Name="$self->{platform}"/></Platforms>
- <Configurations>
-EOF
-
- $self->WriteConfiguration(
- $f, 'Debug',
- {
- defs => "_DEBUG;DEBUG=1",
- wholeopt => 0,
- opt => 0,
- strpool => 'false',
- runtime => 3
- });
- $self->WriteConfiguration(
- $f,
- 'Release',
- {
- defs => "",
- wholeopt => 0,
- opt => 3,
- strpool => 'true',
- runtime => 2
- });
- print $f <<EOF;
- </Configurations>
-EOF
- $self->WriteReferences($f);
- return;
-}
-
-sub WriteFiles
-{
- my ($self, $f) = @_;
- print $f <<EOF;
- <Files>
-EOF
- my @dirstack = ();
- my %uniquefiles;
- foreach my $fileNameWithPath (sort keys %{ $self->{files} })
- {
- confess "Bad format filename '$fileNameWithPath'\n"
- unless ($fileNameWithPath =~ m!^(.*)/([^/]+)\.(c|cpp|y|l|rc)$!);
- my $dir = $1;
- my $file = $2;
-
- # Walk backwards down the directory stack and close any dirs
- # we're done with.
- while ($#dirstack >= 0)
- {
- if (join('/', @dirstack) eq
- substr($dir, 0, length(join('/', @dirstack))))
- {
- last if (length($dir) == length(join('/', @dirstack)));
- last
- if (substr($dir, length(join('/', @dirstack)), 1) eq '/');
- }
- print $f ' ' x $#dirstack . " </Filter>\n";
- pop @dirstack;
- }
-
- # Now walk forwards and create whatever directories are needed
- while (join('/', @dirstack) ne $dir)
- {
- my $left = substr($dir, length(join('/', @dirstack)));
- $left =~ s/^\///;
- my @pieces = split /\//, $left;
- push @dirstack, $pieces[0];
- print $f ' ' x $#dirstack
- . " <Filter Name=\"$pieces[0]\" Filter=\"\">\n";
- }
-
- # VC builds do not like file paths with forward slashes.
- my $fileNameWithPathFormatted = $fileNameWithPath;
- $fileNameWithPathFormatted =~ s/\//\\/g;
-
- print $f ' ' x $#dirstack
- . " <File RelativePath=\"$fileNameWithPathFormatted\"";
- if ($fileNameWithPath =~ /\.y$/)
- {
- my $of = $fileNameWithPath;
- $of =~ s/\.y$/.c/;
- $of =~
- s{^src/pl/plpgsql/src/gram.c$}{src/pl/plpgsql/src/pl_gram.c};
- print $f '>'
- . $self->GenerateCustomTool(
- 'Running bison on ' . $fileNameWithPath,
- "perl src/tools/msvc/pgbison.pl $fileNameWithPath", $of)
- . '</File>' . "\n";
- }
- elsif ($fileNameWithPath =~ /\.l$/)
- {
- my $of = $fileNameWithPath;
- $of =~ s/\.l$/.c/;
- print $f '>'
- . $self->GenerateCustomTool(
- 'Running flex on ' . $fileNameWithPath,
- "perl src/tools/msvc/pgflex.pl $fileNameWithPath", $of)
- . '</File>' . "\n";
- }
- elsif (defined($uniquefiles{$file}))
- {
-
- # File already exists, so fake a new name
- my $obj = $dir;
- $obj =~ s!/!_!g;
- print $f
- "><FileConfiguration Name=\"Debug|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\debug\\$self->{name}\\$obj"
- . "_$file.obj\" /></FileConfiguration><FileConfiguration Name=\"Release|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\release\\$self->{name}\\$obj"
- . "_$file.obj\" /></FileConfiguration></File>\n";
- }
- else
- {
- $uniquefiles{$file} = 1;
- print $f " />\n";
- }
- }
- while ($#dirstack >= 0)
- {
- print $f ' ' x $#dirstack . " </Filter>\n";
- pop @dirstack;
- }
- print $f <<EOF;
- </Files>
-EOF
- return;
-}
-
-sub Footer
-{
- my ($self, $f) = @_;
-
- print $f <<EOF;
- <Globals/>
-</VisualStudioProject>
-EOF
- return;
-}
-
-sub WriteConfiguration
-{
- my ($self, $f, $cfgname, $p) = @_;
- my $cfgtype =
- ($self->{type} eq "exe") ? 1 : ($self->{type} eq "dll" ? 2 : 4);
- my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ' ');
-
- my $targetmachine = $self->{platform} eq 'Win32' ? 1 : 17;
-
- print $f <<EOF;
- <Configuration Name="$cfgname|$self->{platform}" OutputDirectory=".\\$cfgname\\$self->{name}" IntermediateDirectory=".\\$cfgname\\$self->{name}"
- ConfigurationType="$cfgtype" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2" WholeProgramOptimization="$p->{wholeopt}">
- <Tool Name="VCCLCompilerTool" Optimization="$p->{opt}"
- AdditionalIncludeDirectories="$self->{prefixincludes}src/include;src/include/port/win32;src/include/port/win32_msvc;$self->{includes}"
- PreprocessorDefinitions="WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}"
- StringPooling="$p->{strpool}"
- RuntimeLibrary="$p->{runtime}" DisableSpecificWarnings="$self->{disablewarnings}"
- AdditionalOptions="/MP"
-EOF
- print $f <<EOF;
- AssemblerOutput="0" AssemblerListingLocation=".\\$cfgname\\$self->{name}\\" ObjectFile=".\\$cfgname\\$self->{name}\\"
- ProgramDataBaseFileName=".\\$cfgname\\$self->{name}\\" BrowseInformation="0"
- WarningLevel="3" SuppressStartupBanner="TRUE" DebugInformationFormat="3" CompileAs="0"/>
- <Tool Name="VCLinkerTool" OutputFile=".\\$cfgname\\$self->{name}\\$self->{name}.$self->{type}"
- AdditionalDependencies="$libs"
- LinkIncremental="0" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="" IgnoreDefaultLibraryNames="libc"
- StackReserveSize="4194304" DisableSpecificWarnings="$self->{disablewarnings}"
- GenerateDebugInformation="TRUE" ProgramDatabaseFile=".\\$cfgname\\$self->{name}\\$self->{name}.pdb"
- GenerateMapFile="FALSE" MapFileName=".\\$cfgname\\$self->{name}\\$self->{name}.map"
- RandomizedBaseAddress="FALSE"
- SubSystem="1" TargetMachine="$targetmachine"
-EOF
- if ($self->{disablelinkerwarnings})
- {
- print $f
- "\t\tAdditionalOptions=\"/ignore:$self->{disablelinkerwarnings}\"\n";
- }
- if ($self->{implib})
- {
- my $l = $self->{implib};
- $l =~ s/__CFGNAME__/$cfgname/g;
- print $f "\t\tImportLibrary=\"$l\"\n";
- }
- if ($self->{def})
- {
- my $d = $self->{def};
- $d =~ s/__CFGNAME__/$cfgname/g;
- print $f "\t\tModuleDefinitionFile=\"$d\"\n";
- }
-
- print $f "\t/>\n";
- print $f
- "\t<Tool Name=\"VCLibrarianTool\" OutputFile=\".\\$cfgname\\$self->{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\" />\n";
- print $f
- "\t<Tool Name=\"VCResourceCompilerTool\" AdditionalIncludeDirectories=\"src\\include\" />\n";
- if ($self->{builddef})
- {
- print $f
- "\t<Tool Name=\"VCPreLinkEventTool\" Description=\"Generate DEF file\" CommandLine=\"perl src\\tools\\msvc\\gendef.pl $cfgname\\$self->{name} $self->{platform}\" />\n";
- }
- print $f <<EOF;
- </Configuration>
-EOF
- return;
-}
-
-sub WriteReferences
-{
- my ($self, $f) = @_;
- print $f " <References>\n";
- foreach my $ref (@{ $self->{references} })
- {
- print $f
- " <ProjectReference ReferencedProjectIdentifier=\"$ref->{guid}\" Name=\"$ref->{name}\" />\n";
- }
- print $f " </References>\n";
- return;
-}
-
-sub GenerateCustomTool
-{
- my ($self, $desc, $tool, $output, $cfg) = @_;
- if (!defined($cfg))
- {
- return $self->GenerateCustomTool($desc, $tool, $output, 'Debug')
- . $self->GenerateCustomTool($desc, $tool, $output, 'Release');
- }
- return
- "<FileConfiguration Name=\"$cfg|$self->{platform}\"><Tool Name=\"VCCustomBuildTool\" Description=\"$desc\" CommandLine=\"$tool\" AdditionalDependencies=\"\" Outputs=\"$output\" /></FileConfiguration>";
-}
-
-package VC2005Project;
-
-#
-# Package that encapsulates a Visual C++ 2005 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '8.00';
-
- return $self;
-}
-
-package VC2008Project;
-
-#
-# Package that encapsulates a Visual C++ 2008 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '9.00';
-
- return $self;
-}
-
-1;
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 92a4fb6841f..1a94cd866ee 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -13,7 +13,6 @@ use warnings;
use Exporter;
use Project;
use Solution;
-use VCBuildProject;
use MSBuildProject;
our (@ISA, @EXPORT);
@@ -31,23 +30,7 @@ sub CreateSolution
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '8.00')
- {
- return new VS2005Solution(@_);
- }
- elsif ($visualStudioVersion eq '9.00')
- {
- return new VS2008Solution(@_);
- }
- elsif ($visualStudioVersion eq '10.00')
- {
- return new VS2010Solution(@_);
- }
- elsif ($visualStudioVersion eq '11.00')
- {
- return new VS2012Solution(@_);
- }
- elsif ($visualStudioVersion eq '12.00')
+ if ($visualStudioVersion eq '12.00')
{
return new VS2013Solution(@_);
}
@@ -78,23 +61,7 @@ sub CreateProject
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '8.00')
- {
- return new VC2005Project(@_);
- }
- elsif ($visualStudioVersion eq '9.00')
- {
- return new VC2008Project(@_);
- }
- elsif ($visualStudioVersion eq '10.00')
- {
- return new VC2010Project(@_);
- }
- elsif ($visualStudioVersion eq '11.00')
- {
- return new VC2012Project(@_);
- }
- elsif ($visualStudioVersion eq '12.00')
+ if ($visualStudioVersion eq '12.00')
{
return new VC2013Project(@_);
}
--
2.18.0.rc2.dirty
[text/x-diff] v1-0003-Introduce-minimal-C99-usage-to-verify-compiler-su.patch (5.0K, ../../20180823000905.fjthfohmczss4fiw@alap3.anarazel.de/4-v1-0003-Introduce-minimal-C99-usage-to-verify-compiler-su.patch)
download | inline diff:
From e0a39e6ecd0542ee8274351e2e3ed3655b85f15f Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:44:33 -0700
Subject: [PATCH v1 3/4] Introduce minimal C99 usage to verify compiler
support.
This just converts a few for loops in postgres.c to declare variables
in the loop initializer, and uses designated initializers in smgr.c's
definition of smgr callbacks.
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
src/backend/storage/smgr/smgr.c | 21 ++++++++++++++++++---
src/backend/tcop/postgres.c | 25 +++++++------------------
2 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 08f06bade25..189342ef86a 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -67,9 +67,24 @@ typedef struct f_smgr
static const f_smgr smgrsw[] = {
/* magnetic disk */
- {mdinit, NULL, mdclose, mdcreate, mdexists, mdunlink, mdextend,
- mdprefetch, mdread, mdwrite, mdwriteback, mdnblocks, mdtruncate,
- mdimmedsync, mdpreckpt, mdsync, mdpostckpt
+ {
+ .smgr_init = mdinit,
+ .smgr_shutdown = NULL,
+ .smgr_close = mdclose,
+ .smgr_create = mdcreate,
+ .smgr_exists = mdexists,
+ .smgr_unlink = mdunlink,
+ .smgr_extend = mdextend,
+ .smgr_prefetch = mdprefetch,
+ .smgr_read = mdread,
+ .smgr_write = mdwrite,
+ .smgr_writeback = mdwriteback,
+ .smgr_nblocks = mdnblocks,
+ .smgr_truncate = mdtruncate,
+ .smgr_immedsync = mdimmedsync,
+ .smgr_pre_ckpt = mdpreckpt,
+ .smgr_sync = mdsync,
+ .smgr_post_ckpt = mdpostckpt
}
};
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 07b956553a7..7a9ada2c719 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -1310,7 +1310,6 @@ exec_parse_message(const char *query_string, /* string to execute */
{
Query *query;
bool snapshot_set = false;
- int i;
raw_parse_tree = linitial_node(RawStmt, parsetree_list);
@@ -1366,7 +1365,7 @@ exec_parse_message(const char *query_string, /* string to execute */
/*
* Check all parameter types got determined.
*/
- for (i = 0; i < numParams; i++)
+ for (int i = 0; i < numParams; i++)
{
Oid ptype = paramTypes[i];
@@ -1555,10 +1554,8 @@ exec_bind_message(StringInfo input_message)
numPFormats = pq_getmsgint(input_message, 2);
if (numPFormats > 0)
{
- int i;
-
pformats = (int16 *) palloc(numPFormats * sizeof(int16));
- for (i = 0; i < numPFormats; i++)
+ for (int i = 0; i < numPFormats; i++)
pformats[i] = pq_getmsgint(input_message, 2);
}
@@ -1641,8 +1638,6 @@ exec_bind_message(StringInfo input_message)
*/
if (numParams > 0)
{
- int paramno;
-
params = (ParamListInfo) palloc(offsetof(ParamListInfoData, params) +
numParams * sizeof(ParamExternData));
/* we have static list of params, so no hooks needed */
@@ -1654,7 +1649,7 @@ exec_bind_message(StringInfo input_message)
params->parserSetupArg = NULL;
params->numParams = numParams;
- for (paramno = 0; paramno < numParams; paramno++)
+ for (int paramno = 0; paramno < numParams; paramno++)
{
Oid ptype = psrc->param_types[paramno];
int32 plength;
@@ -1782,10 +1777,8 @@ exec_bind_message(StringInfo input_message)
numRFormats = pq_getmsgint(input_message, 2);
if (numRFormats > 0)
{
- int i;
-
rformats = (int16 *) palloc(numRFormats * sizeof(int16));
- for (i = 0; i < numRFormats; i++)
+ for (int i = 0; i < numRFormats; i++)
rformats[i] = pq_getmsgint(input_message, 2);
}
@@ -2212,7 +2205,6 @@ errdetail_params(ParamListInfo params)
{
StringInfoData param_str;
MemoryContext oldcontext;
- int paramno;
/* This code doesn't support dynamic param lists */
Assert(params->paramFetch == NULL);
@@ -2222,7 +2214,7 @@ errdetail_params(ParamListInfo params)
initStringInfo(¶m_str);
- for (paramno = 0; paramno < params->numParams; paramno++)
+ for (int paramno = 0; paramno < params->numParams; paramno++)
{
ParamExternData *prm = ¶ms->params[paramno];
Oid typoutput;
@@ -2325,7 +2317,6 @@ static void
exec_describe_statement_message(const char *stmt_name)
{
CachedPlanSource *psrc;
- int i;
/*
* Start up a transaction command. (Note that this will normally change
@@ -2384,7 +2375,7 @@ exec_describe_statement_message(const char *stmt_name)
* message type */
pq_sendint16(&row_description_buf, psrc->num_params);
- for (i = 0; i < psrc->num_params; i++)
+ for (int i = 0; i < psrc->num_params; i++)
{
Oid ptype = psrc->param_types[i];
@@ -4179,10 +4170,8 @@ PostgresMain(int argc, char *argv[],
numParams = pq_getmsgint(&input_message, 2);
if (numParams > 0)
{
- int i;
-
paramTypes = (Oid *) palloc(numParams * sizeof(Oid));
- for (i = 0; i < numParams; i++)
+ for (int i = 0; i < numParams; i++)
paramTypes[i] = pq_getmsgint(&input_message, 4);
}
pq_getmsgend(&input_message);
--
2.18.0.rc2.dirty
[text/x-diff] v1-0004-robot-Add-CI-control-files.patch (5.7K, ../../20180823000905.fjthfohmczss4fiw@alap3.anarazel.de/5-v1-0004-robot-Add-CI-control-files.patch)
download | inline diff:
From 1905cc80e205f390cdc7acfe79293dce969eed68 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:18:59 -0700
Subject: [PATCH v1 4/4] [robot] Add CI control files
This commit adds control files to trigger building and testing. It is not
part of the patch set.
---
.travis.yml | 34 ++++++++++++++++++++++++++++++++++
README.md | 21 +++++++++++++++++++++
appveyor.yml | 27 +++++++++++++++++++++++++++
buildsetup.pl | 38 ++++++++++++++++++++++++++++++++++++++
dumpregr.pl | 20 ++++++++++++++++++++
5 files changed, 140 insertions(+)
create mode 100644 .travis.yml
create mode 100644 README.md
create mode 100644 appveyor.yml
create mode 100644 buildsetup.pl
create mode 100644 dumpregr.pl
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 00000000000..08ef1fbf9a0
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,34 @@
+sudo: required
+addons:
+ apt:
+ packages:
+ - gdb
+ - lcov
+ - libipc-run-perl
+ - libperl-dev
+ - libpython-dev
+ - tcl-dev
+ - libldap2-dev
+ - libicu-dev
+ - docbook
+ - docbook-dsssl
+ - docbook-xsl
+ - libxml2-utils
+ - openjade1.3
+ - opensp
+ - xsltproc
+language: c
+cache: ccache
+before_install:
+ - echo '/tmp/%e-%s-%p.core' | sudo tee /proc/sys/kernel/core_pattern
+script: ./configure --enable-debug --enable-cassert --enable-coverage --enable-tap-tests --with-tcl --with-python --with-perl --with-ldap --with-icu && make -j4 all contrib docs && make check-world
+#after_success:
+# - bash <(curl -s https://codecov.io/bash)
+after_failure:
+ - for f in $(find . -name regression.diffs) ; do echo "========= Contents of $f" ; head -1000 $f ; done
+ - |
+ for corefile in $(find /tmp/ -name '*.core' 2>/dev/null) ; do
+ binary=$(gdb -quiet -core $corefile -batch -ex 'info auxv' | grep AT_EXECFN | perl -pe "s/^.*\"(.*)\"\$/\$1/g")
+ echo dumping $corefile for $binary
+ gdb --batch --quiet -ex "thread apply all bt full" -ex "quit" $binary $corefile
+ done
diff --git a/README.md b/README.md
new file mode 100644
index 00000000000..81e7b3c27ad
--- /dev/null
+++ b/README.md
@@ -0,0 +1,21 @@
+Zheap Part I: Undo Log Storage
+
+This branch is maintained by a robot. It is automatically filtered and
+combined from the commit history in the zheap-tmunro branch at
+at https://github.com/EnterpriseDB/zheap into a more presentable form.
+It's a preview of the lowest level patch-set in the Zheap proposal.
+It's work in progress.
+
+There are five patches in this patch set:
+
+* [0001-Add-undo-log-manager.patch](../../commit/417481eaf562a36808cc7dbdbffbdef0361eff4f)
+* [0002-Provide-access-to-undo-log-data-via-the-buffer-manager.patch](../../commit/88ce7dcbf20f243649aea1bd0ca3f42c7e0cc129)
+* [0003-Add-developer-documentation-for-the-undo-log-manager.patch](../../commit/0c741fec6ffa4e69436a7e38dabc85b388477297)
+* [0004-Add-tests-for-the-undo-log-manager.patch](../../commit/5d44b81eab636cb7f002704ca685af8a2800024b)
+* [0005-Add-user-facing-documentation-for-undo-logs.patch](../../commit/892e5202b1c45a3f2032d4bef671413268738348)
+
+This branch is automatically tested by:
+
+* Ubuntu build bot over at Travis CI: [<img src="https://travis-ci.org/macdice/postgres.svg?branch=undo-log-storage"/>](https://travis-ci.org/macdice/postgres/branches)
+* Windows build bot over at AppVeyor: [<img src="https://ci.appveyor.com/api/projects/status/github/macdice?branch=undo-log-storage&svg=true"/>](https://ci.appveyor.com/project/macdice/postgres/branch/undo-log-storage)
+
diff --git a/appveyor.yml b/appveyor.yml
new file mode 100644
index 00000000000..af1ce3da32a
--- /dev/null
+++ b/appveyor.yml
@@ -0,0 +1,27 @@
+# appveyor.yml
+install:
+ - cinst winflexbison
+ - '"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64'
+ - '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86_amd64'
+
+
+before_build:
+ - rename c:\ProgramData\chocolatey\bin\win_flex.exe flex.exe
+ - rename c:\ProgramData\chocolatey\bin\win_bison.exe bison.exe
+ - perl buildsetup.pl
+
+build:
+ project: pgsql.sln
+
+before_test:
+ - 'perl -p -i.bak -e "s/^test: tablespace/#test: tablespace/" src/test/regress/serial_schedule'
+ - 'perl -p -i.bak -e "s/^test: tablespace/#test: tablespace/" src/test/regress/parallel_schedule'
+
+test_script:
+ - cd src\tools\msvc && vcregress check
+
+on_failure:
+ - perl dumpregr.pl
+
+configuration:
+ - Release
diff --git a/buildsetup.pl b/buildsetup.pl
new file mode 100644
index 00000000000..23df2fb1aa4
--- /dev/null
+++ b/buildsetup.pl
@@ -0,0 +1,38 @@
+# first part of postgres build.pl, just doesn't run msbuild
+
+use strict;
+
+BEGIN
+{
+
+ chdir("../../..") if (-d "../msvc" && -d "../../../src");
+
+}
+
+use lib "src/tools/msvc";
+
+use Cwd;
+
+use Mkvcbuild;
+
+# buildenv.pl is for specifying the build environment settings
+# it should contain lines like:
+# $ENV{PATH} = "c:/path/to/bison/bin;$ENV{PATH}";
+
+if (-e "src/tools/msvc/buildenv.pl")
+{
+ do "src/tools/msvc/buildenv.pl";
+}
+elsif (-e "./buildenv.pl")
+{
+ do "./buildenv.pl";
+}
+
+# set up the project
+our $config;
+do "config_default.pl";
+do "config.pl" if (-f "src/tools/msvc/config.pl");
+
+# print "PATH: $_\n" foreach (split(';',$ENV{PATH}));
+
+Mkvcbuild::mkvcbuild($config);
diff --git a/dumpregr.pl b/dumpregr.pl
new file mode 100644
index 00000000000..d9039da7844
--- /dev/null
+++ b/dumpregr.pl
@@ -0,0 +1,20 @@
+use strict;
+use warnings FATAL => qw(all);
+
+use File::Find;
+
+my $Target = "regression.diffs";
+
+find(\&dump, "src");
+
+sub dump {
+ if ($_ eq $Target) {
+ my $path = $File::Find::name;
+ print "=== $path ===\n";
+ open(my $fh, "<", $_) || die "wtf";
+ while (my $line = <$fh>) {
+ print $line;
+ if ($. > 1000) { last; }
+ }
+ }
+}
--
2.18.0.rc2.dirty
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-23 00:16 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 37+ messages in thread
From: Tom Lane @ 2018-08-23 00:16 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Andres Freund <andres@anarazel.de> writes:
> There's a few further potential cleanups due to relying on c99:
> - Use __func__ unconditionally, rather than having configure test for it
> - Use inline unconditionally, rather than having configure test for it
> - Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
> AC_TYPE_LONG_LONG_INT, we can rely on them being present.
> - probably more in that vein
I wouldn't be in too much of a hurry to do that, particularly not the
third item. You are confusing "compiler is c99" with "system headers
are c99". Moreover, I don't see that we're buying much with such
changes.
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-23 00:19 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-23 00:19 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Hi,
On 2018-08-22 20:16:24 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > There's a few further potential cleanups due to relying on c99:
> > - Use __func__ unconditionally, rather than having configure test for it
> > - Use inline unconditionally, rather than having configure test for it
> > - Remove tests for AC_TYPE_INTPTR_T, AC_TYPE_UINTPTR_T,
> > AC_TYPE_LONG_LONG_INT, we can rely on them being present.
> > - probably more in that vein
>
> I wouldn't be in too much of a hurry to do that, particularly not the
> third item. You are confusing "compiler is c99" with "system headers
> are c99". Moreover, I don't see that we're buying much with such
> changes.
Yea, I am not in much of a hurry on any of them. I think the only
argument for them is that it'd buy us a littlebit of a reduction in
configure runtime...
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-23 01:31 Andres Freund <andres@anarazel.de>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 37+ messages in thread
From: Andres Freund @ 2018-08-23 01:31 UTC (permalink / raw)
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
> Attached is a version doing so.
Mildly updated version attached. This adds an explanatory commit
message, removes one stray docs C89 reference, and fixes a mis-squashing
of a patch.
Greetings,
Andres Freund
Attachments:
[text/x-diff] v2-0001-Require-C99-and-thus-MSCV-2013-upwards.patch (28.3K, ../../20180823013134.3h4j62eeiaibpgvo@alap3.anarazel.de/2-v2-0001-Require-C99-and-thus-MSCV-2013-upwards.patch)
download | inline diff:
From 4b63f3307180a778018439ad3dee9a89aa4f4352 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 15:10:23 -0700
Subject: [PATCH v2 1/4] Require C99 (and thus MSCV 2013 upwards).
In 86d78ef50e01 I enabled configure to check for C99 support, with the
goal of checking which platforms support C99. While there are a few
machines without C99 support, de-supporting them for v12 was deemed
acceptable.
While not tested in aforementioned commit, the biggest increase in
minimum version comes from MSVC, which gained C99 support fairly
late. The subset in MSVC 2013 is sufficient for our needs, at this
point. While that is a significant increase in minimum version, the
existing windows binaries are already built with a new enough version.
Make configure error out if C99 support could not be detected. For
MSVC builds, increase the minimum version to 2013.
The increase to MSVC 2013 allows us to get rid of VCBuildProject.pm,
as that was only required for MSVC 2005/2008.
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
configure | 49 +++++
configure.in | 10 +
doc/src/sgml/install-windows.sgml | 26 +--
doc/src/sgml/installation.sgml | 2 +-
doc/src/sgml/sources.sgml | 33 ++--
src/tools/msvc/MSBuildProject.pm | 78 +-------
src/tools/msvc/README | 18 +-
src/tools/msvc/Solution.pm | 102 ----------
src/tools/msvc/VCBuildProject.pm | 309 ------------------------------
src/tools/msvc/VSObjectFactory.pm | 37 +---
src/tools/msvc/build.pl | 6 +-
11 files changed, 112 insertions(+), 558 deletions(-)
delete mode 100644 src/tools/msvc/VCBuildProject.pm
diff --git a/configure b/configure
index 836d68dad37..dd439ddd2f6 100755
--- a/configure
+++ b/configure
@@ -4602,6 +4602,13 @@ if test "x$ac_cv_prog_cc_c99" != xno; then :
fi
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+ as_fn_error $? "C compiler \"$CC\" does not support C99" "$LINENO" 5
+fi
+
ac_ext=cpp
ac_cpp='$CXXCPP $CPPFLAGS'
ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
@@ -5361,6 +5368,48 @@ fi
# -Wdeclaration-after-statement isn't applicable for C++
+ # Really don't want VLAs to be used in our dialect of C
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Werror=vla, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -Werror=vla, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__Werror_vla+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -Werror=vla"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h. */
+
+int
+main ()
+{
+
+ ;
+ return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+ pgac_cv_prog_CC_cflags__Werror_vla=yes
+else
+ pgac_cv_prog_CC_cflags__Werror_vla=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Werror_vla" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__Werror_vla" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__Werror_vla" = x"yes"; then
+ CFLAGS="${CFLAGS} -Werror=vla"
+fi
+
+
+ # -Wvla is not applicable for C++
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wendif-labels, for CFLAGS" >&5
$as_echo_n "checking whether ${CC} supports -Wendif-labels, for CFLAGS... " >&6; }
diff --git a/configure.in b/configure.in
index 6e141064e5c..5869ab7c5bc 100644
--- a/configure.in
+++ b/configure.in
@@ -359,6 +359,13 @@ esac
AC_PROG_CC([$pgac_cc_list])
AC_PROG_CC_C99()
+
+# Error out if the compiler does not support C99, as the codebase
+# relies on that.
+if test "$ac_cv_prog_cc_c99" = no; then
+ AC_MSG_ERROR([C compiler "$CC" does not support C99])
+fi
+
AC_PROG_CXX([$pgac_cxx_list])
# Check if it's Intel's compiler, which (usually) pretends to be gcc,
@@ -477,6 +484,9 @@ if test "$GCC" = yes -a "$ICC" = no; then
# These work in some but not all gcc versions
PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])
# -Wdeclaration-after-statement isn't applicable for C++
+ # Really don't want VLAs to be used in our dialect of C
+ PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
+ # -Wvla is not applicable for C++
PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 9597bc35a14..22a2ffd55ee 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -22,7 +22,7 @@
Microsoft tools is to install <productname>Visual Studio Express 2017
for Windows Desktop</productname> and use the included
compiler. It is also possible to build with the full
- <productname>Microsoft Visual C++ 2005 to 2017</productname>.
+ <productname>Microsoft Visual C++ 2013 to 2017</productname>.
In some cases that requires the installation of the
<productname>Windows SDK</productname> in addition to the compiler.
</para>
@@ -77,20 +77,24 @@
<para>
Both 32-bit and 64-bit builds are possible with the Microsoft Compiler suite.
32-bit PostgreSQL builds are possible with
- <productname>Visual Studio 2005</productname> to
+ <productname>Visual Studio 2013</productname> to
<productname>Visual Studio 2017</productname> (including Express editions),
as well as standalone Windows SDK releases 6.0 to 8.1.
64-bit PostgreSQL builds are supported with
<productname>Microsoft Windows SDK</productname> version 6.0a to 8.1 or
- <productname>Visual Studio 2008</productname> and above. Compilation
- is supported down to <productname>Windows XP</productname> and
- <productname>Windows Server 2003</productname> when building with
- <productname>Visual Studio 2005</productname> to
- <productname>Visual Studio 2013</productname>. Building with
- <productname>Visual Studio 2015</productname> is supported down to
- <productname>Windows Vista</productname> and <productname>Windows Server 2008</productname>.
- Building with <productname>Visual Studio 2017</productname> is supported
- down to <productname>Windows 7 SP1</productname> and <productname>Windows Server 2008 R2 SP1</productname>.
+ <productname>Visual Studio 2013</productname> and above. Compilation
+ is supported down to <productname>Windows 7</productname> and
+ <productname>Windows Server 2008 R2 SP1</productname> when building with
+ <productname>Visual Studio 2013</productname> to
+ <productname>Visual Studio 2017</productname>.
+ <!--
+ For 2013 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
+ For 2015 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2015-sysrequirements-vs
+ For 2017 requirements:
+ https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2017-system-requirements-vs
+ -->
</para>
<para>
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 10c925d2905..4487d0cfd17 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -85,7 +85,7 @@ su - postgres
<listitem>
<para>
You need an <acronym>ISO</acronym>/<acronym>ANSI</acronym> C compiler (at least
- C89-compliant). Recent
+ C99-compliant). Recent
versions of <productname>GCC</productname> are recommended, but
<productname>PostgreSQL</productname> is known to build using a wide variety
of compilers from different vendors.
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index e53ee1dc6ad..419f753c7bc 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -867,19 +867,30 @@ BETTER: unrecognized node type: 42
<title>C Standard</title>
<para>
Code in <productname>PostgreSQL</productname> should only rely on language
- features available in the C89 standard. That means a conforming
- C89 compiler has to be able to compile postgres, at least aside
- from a few platform dependent pieces. Features from later
- revision of the C standard or compiler specific features can be
- used, if a fallback is provided.
+ features available in the C99 standard. That means a conforming
+ C99 compiler has to be able to compile postgres, at least aside
+ from a few platform dependent pieces.
</para>
<para>
- For example <literal>static inline</literal> and
- <literal>_StaticAssert()</literal> are currently used, even
- though they are from newer revisions of the C standard. If not
- available we respectively fall back to defining the functions
- without inline, and to using a C89 compatible replacement that
- performs the same checks, but emits rather cryptic messages.
+ A few features included in the C99 standard are, at this time, not be
+ permitted to be used in core <productname>PostgreSQL</productname>
+ code. This currently includes variable length arrays, intermingled
+ declarations and code, <literal>//</literal> comments, universal
+ character names. Reasons for that include portability and historical
+ practices.
+ </para>
+ <para>
+ Features from later revision of the C standard or compiler specific
+ features can be used, if a fallback is provided.
+ </para>
+ <para>
+ For example <literal>_StaticAssert()</literal> and
+ <literal>__builtin_constant_p</literal> are currently used, even though
+ they are from newer revisions of the C standard and a
+ <productname>GCC</productname> extension respectively. If not available
+ we respectively fall back to using a C99 compatible replacement that
+ performs the same checks, but emits rather cryptic messages and do not
+ use <literal>__builtin_constant_p</literal>.
</para>
</simplesect>
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index 47252533a1b..149213378cf 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -1,7 +1,7 @@
package MSBuildProject;
#
-# Package that encapsulates a MSBuild project file (Visual C++ 2010 or greater)
+# Package that encapsulates a MSBuild project file (Visual C++ 2013 or greater)
#
# src/tools/msvc/MSBuildProject.pm
#
@@ -257,6 +257,7 @@ sub WriteConfigurationPropertyGroup
<UseOfMfc>false</UseOfMfc>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
+ <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
</PropertyGroup>
EOF
return;
@@ -391,75 +392,6 @@ EOF
return;
}
-package VC2010Project;
-
-#
-# Package that encapsulates a Visual C++ 2010 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '10.00';
-
- return $self;
-}
-
-package VC2012Project;
-
-#
-# Package that encapsulates a Visual C++ 2012 project file
-#
-
-use strict;
-use warnings;
-use base qw(MSBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '11.00';
- $self->{PlatformToolset} = 'v110';
-
- return $self;
-}
-
-# This override adds the <PlatformToolset> element
-# to the PropertyGroup labeled "Configuration"
-sub WriteConfigurationPropertyGroup
-{
- my ($self, $f, $cfgname, $p) = @_;
- my $cfgtype =
- ($self->{type} eq "exe")
- ? 'Application'
- : ($self->{type} eq "dll" ? 'DynamicLibrary' : 'StaticLibrary');
-
- print $f <<EOF;
- <PropertyGroup Condition="'\$(Configuration)|\$(Platform)'=='$cfgname|$self->{platform}'" Label="Configuration">
- <ConfigurationType>$cfgtype</ConfigurationType>
- <UseOfMfc>false</UseOfMfc>
- <CharacterSet>MultiByte</CharacterSet>
- <WholeProgramOptimization>$p->{wholeopt}</WholeProgramOptimization>
- <PlatformToolset>$self->{PlatformToolset}</PlatformToolset>
- </PropertyGroup>
-EOF
- return;
-}
-
package VC2013Project;
#
@@ -468,7 +400,7 @@ package VC2013Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
@@ -493,7 +425,7 @@ package VC2015Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
@@ -518,7 +450,7 @@ package VC2017Project;
use strict;
use warnings;
-use base qw(VC2012Project);
+use base qw(MSBuildProject);
no warnings qw(redefine); ## no critic
diff --git a/src/tools/msvc/README b/src/tools/msvc/README
index bfa98045f22..4ab81d3402f 100644
--- a/src/tools/msvc/README
+++ b/src/tools/msvc/README
@@ -4,7 +4,7 @@ MSVC build
==========
This directory contains the tools required to build PostgreSQL using
-Microsoft Visual Studio 2005 - 2017. This builds the whole backend, not just
+Microsoft Visual Studio 2013 - 2017. This builds the whole backend, not just
the libpq frontend library. For more information, see the documentation
chapter "Installation on Windows" and the description below.
@@ -67,14 +67,12 @@ Install.pm module containing the install logic
Mkvcbuild.pm module containing the code to generate the Visual
Studio build (project/solution) files
MSBuildProject.pm module containing the code to generate MSBuild based
- project files (Visual Studio 2010 or greater)
+ project files (Visual Studio 2013 or greater)
Project.pm module containing the common code to generate the
Visual Studio project files. Also provides the
common interface of all project file generators
Solution.pm module containing the code to generate the Visual
Studio solution files.
-VCBuildProject.pm module containing the code to generate VCBuild based
- project files (Visual Studio 2005/2008)
VSObjectFactory.pm factory module providing the code to create the
appropriate project/solution files for the current
environment
@@ -90,14 +88,12 @@ config_default.pl to create the configuration arguments.
These configuration arguments are passed over to Mkvcbuild::mkvcbuild
(Mkvcbuild.pm) which creates the Visual Studio project and solution files.
It does this by using VSObjectFactory::CreateSolution to create an object
-implementing the Solution interface (this could be either a VS2005Solution,
-a VS2008Solution, a VS2010Solution or a VS2012Solution or a VS2013Solution,
+implementing the Solution interface (this could be either a VS2013Solution,
or a VS2015Solution or a VS2017Solution, all in Solution.pm, depending on
the user's build environment) and adding objects implementing the corresponding
-Project interface (VC2005Project or VC2008Project from VCBuildProject.pm or
-VC2010Project or VC2012Project or VC2013Project or VC2015Project or VC2017Project
-from MSBuildProject.pm) to it.
+Project interface (VC2013Project or VC2015Project or VC2017Project from
+MSBuildProject.pm) to it.
When Solution::Save is called, the implementations of Solution and Project
save their content in the appropriate format.
-The final step of starting the appropriate build program (msbuild or vcbuild)
-is performed in build.pl again.
+The final step of starting the appropriate build program (msbuild) is
+performed in build.pl again.
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 78db247b291..7d7ce8b0312 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -760,108 +760,6 @@ sub GetFakeConfigure
return $cfg;
}
-package VS2005Solution;
-
-#
-# Package that encapsulates a Visual Studio 2005 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '9.00';
- $self->{vcver} = '8.00';
- $self->{visualStudioName} = 'Visual Studio 2005';
-
- return $self;
-}
-
-package VS2008Solution;
-
-#
-# Package that encapsulates a Visual Studio 2008 solution file
-#
-
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '10.00';
- $self->{vcver} = '9.00';
- $self->{visualStudioName} = 'Visual Studio 2008';
-
- return $self;
-}
-
-package VS2010Solution;
-
-#
-# Package that encapsulates a Visual Studio 2010 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '11.00';
- $self->{vcver} = '10.00';
- $self->{visualStudioName} = 'Visual Studio 2010';
-
- return $self;
-}
-
-package VS2012Solution;
-
-#
-# Package that encapsulates a Visual Studio 2012 solution file
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Solution);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{solutionFileVersion} = '12.00';
- $self->{vcver} = '11.00';
- $self->{visualStudioName} = 'Visual Studio 2012';
-
- return $self;
-}
-
package VS2013Solution;
#
diff --git a/src/tools/msvc/VCBuildProject.pm b/src/tools/msvc/VCBuildProject.pm
deleted file mode 100644
index 6cdf822a637..00000000000
--- a/src/tools/msvc/VCBuildProject.pm
+++ /dev/null
@@ -1,309 +0,0 @@
-package VCBuildProject;
-
-#
-# Package that encapsulates a VCBuild (Visual C++ 2005/2008) project file
-#
-# src/tools/msvc/VCBuildProject.pm
-#
-
-use Carp;
-use strict;
-use warnings;
-use base qw(Project);
-
-no warnings qw(redefine); ## no critic
-
-sub _new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{filenameExtension} = '.vcproj';
-
- return $self;
-}
-
-sub WriteHeader
-{
- my ($self, $f) = @_;
-
- print $f <<EOF;
-<?xml version="1.0" encoding="Windows-1252"?>
-<VisualStudioProject ProjectType="Visual C++" Version="$self->{vcver}" Name="$self->{name}" ProjectGUID="$self->{guid}">
- <Platforms><Platform Name="$self->{platform}"/></Platforms>
- <Configurations>
-EOF
-
- $self->WriteConfiguration(
- $f, 'Debug',
- {
- defs => "_DEBUG;DEBUG=1",
- wholeopt => 0,
- opt => 0,
- strpool => 'false',
- runtime => 3
- });
- $self->WriteConfiguration(
- $f,
- 'Release',
- {
- defs => "",
- wholeopt => 0,
- opt => 3,
- strpool => 'true',
- runtime => 2
- });
- print $f <<EOF;
- </Configurations>
-EOF
- $self->WriteReferences($f);
- return;
-}
-
-sub WriteFiles
-{
- my ($self, $f) = @_;
- print $f <<EOF;
- <Files>
-EOF
- my @dirstack = ();
- my %uniquefiles;
- foreach my $fileNameWithPath (sort keys %{ $self->{files} })
- {
- confess "Bad format filename '$fileNameWithPath'\n"
- unless ($fileNameWithPath =~ m!^(.*)/([^/]+)\.(c|cpp|y|l|rc)$!);
- my $dir = $1;
- my $file = $2;
-
- # Walk backwards down the directory stack and close any dirs
- # we're done with.
- while ($#dirstack >= 0)
- {
- if (join('/', @dirstack) eq
- substr($dir, 0, length(join('/', @dirstack))))
- {
- last if (length($dir) == length(join('/', @dirstack)));
- last
- if (substr($dir, length(join('/', @dirstack)), 1) eq '/');
- }
- print $f ' ' x $#dirstack . " </Filter>\n";
- pop @dirstack;
- }
-
- # Now walk forwards and create whatever directories are needed
- while (join('/', @dirstack) ne $dir)
- {
- my $left = substr($dir, length(join('/', @dirstack)));
- $left =~ s/^\///;
- my @pieces = split /\//, $left;
- push @dirstack, $pieces[0];
- print $f ' ' x $#dirstack
- . " <Filter Name=\"$pieces[0]\" Filter=\"\">\n";
- }
-
- # VC builds do not like file paths with forward slashes.
- my $fileNameWithPathFormatted = $fileNameWithPath;
- $fileNameWithPathFormatted =~ s/\//\\/g;
-
- print $f ' ' x $#dirstack
- . " <File RelativePath=\"$fileNameWithPathFormatted\"";
- if ($fileNameWithPath =~ /\.y$/)
- {
- my $of = $fileNameWithPath;
- $of =~ s/\.y$/.c/;
- $of =~
- s{^src/pl/plpgsql/src/gram.c$}{src/pl/plpgsql/src/pl_gram.c};
- print $f '>'
- . $self->GenerateCustomTool(
- 'Running bison on ' . $fileNameWithPath,
- "perl src/tools/msvc/pgbison.pl $fileNameWithPath", $of)
- . '</File>' . "\n";
- }
- elsif ($fileNameWithPath =~ /\.l$/)
- {
- my $of = $fileNameWithPath;
- $of =~ s/\.l$/.c/;
- print $f '>'
- . $self->GenerateCustomTool(
- 'Running flex on ' . $fileNameWithPath,
- "perl src/tools/msvc/pgflex.pl $fileNameWithPath", $of)
- . '</File>' . "\n";
- }
- elsif (defined($uniquefiles{$file}))
- {
-
- # File already exists, so fake a new name
- my $obj = $dir;
- $obj =~ s!/!_!g;
- print $f
- "><FileConfiguration Name=\"Debug|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\debug\\$self->{name}\\$obj"
- . "_$file.obj\" /></FileConfiguration><FileConfiguration Name=\"Release|$self->{platform}\"><Tool Name=\"VCCLCompilerTool\" ObjectFile=\".\\release\\$self->{name}\\$obj"
- . "_$file.obj\" /></FileConfiguration></File>\n";
- }
- else
- {
- $uniquefiles{$file} = 1;
- print $f " />\n";
- }
- }
- while ($#dirstack >= 0)
- {
- print $f ' ' x $#dirstack . " </Filter>\n";
- pop @dirstack;
- }
- print $f <<EOF;
- </Files>
-EOF
- return;
-}
-
-sub Footer
-{
- my ($self, $f) = @_;
-
- print $f <<EOF;
- <Globals/>
-</VisualStudioProject>
-EOF
- return;
-}
-
-sub WriteConfiguration
-{
- my ($self, $f, $cfgname, $p) = @_;
- my $cfgtype =
- ($self->{type} eq "exe") ? 1 : ($self->{type} eq "dll" ? 2 : 4);
- my $libs = $self->GetAdditionalLinkerDependencies($cfgname, ' ');
-
- my $targetmachine = $self->{platform} eq 'Win32' ? 1 : 17;
-
- print $f <<EOF;
- <Configuration Name="$cfgname|$self->{platform}" OutputDirectory=".\\$cfgname\\$self->{name}" IntermediateDirectory=".\\$cfgname\\$self->{name}"
- ConfigurationType="$cfgtype" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2" WholeProgramOptimization="$p->{wholeopt}">
- <Tool Name="VCCLCompilerTool" Optimization="$p->{opt}"
- AdditionalIncludeDirectories="$self->{prefixincludes}src/include;src/include/port/win32;src/include/port/win32_msvc;$self->{includes}"
- PreprocessorDefinitions="WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}"
- StringPooling="$p->{strpool}"
- RuntimeLibrary="$p->{runtime}" DisableSpecificWarnings="$self->{disablewarnings}"
- AdditionalOptions="/MP"
-EOF
- print $f <<EOF;
- AssemblerOutput="0" AssemblerListingLocation=".\\$cfgname\\$self->{name}\\" ObjectFile=".\\$cfgname\\$self->{name}\\"
- ProgramDataBaseFileName=".\\$cfgname\\$self->{name}\\" BrowseInformation="0"
- WarningLevel="3" SuppressStartupBanner="TRUE" DebugInformationFormat="3" CompileAs="0"/>
- <Tool Name="VCLinkerTool" OutputFile=".\\$cfgname\\$self->{name}\\$self->{name}.$self->{type}"
- AdditionalDependencies="$libs"
- LinkIncremental="0" SuppressStartupBanner="TRUE" AdditionalLibraryDirectories="" IgnoreDefaultLibraryNames="libc"
- StackReserveSize="4194304" DisableSpecificWarnings="$self->{disablewarnings}"
- GenerateDebugInformation="TRUE" ProgramDatabaseFile=".\\$cfgname\\$self->{name}\\$self->{name}.pdb"
- GenerateMapFile="FALSE" MapFileName=".\\$cfgname\\$self->{name}\\$self->{name}.map"
- RandomizedBaseAddress="FALSE"
- SubSystem="1" TargetMachine="$targetmachine"
-EOF
- if ($self->{disablelinkerwarnings})
- {
- print $f
- "\t\tAdditionalOptions=\"/ignore:$self->{disablelinkerwarnings}\"\n";
- }
- if ($self->{implib})
- {
- my $l = $self->{implib};
- $l =~ s/__CFGNAME__/$cfgname/g;
- print $f "\t\tImportLibrary=\"$l\"\n";
- }
- if ($self->{def})
- {
- my $d = $self->{def};
- $d =~ s/__CFGNAME__/$cfgname/g;
- print $f "\t\tModuleDefinitionFile=\"$d\"\n";
- }
-
- print $f "\t/>\n";
- print $f
- "\t<Tool Name=\"VCLibrarianTool\" OutputFile=\".\\$cfgname\\$self->{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\" />\n";
- print $f
- "\t<Tool Name=\"VCResourceCompilerTool\" AdditionalIncludeDirectories=\"src\\include\" />\n";
- if ($self->{builddef})
- {
- print $f
- "\t<Tool Name=\"VCPreLinkEventTool\" Description=\"Generate DEF file\" CommandLine=\"perl src\\tools\\msvc\\gendef.pl $cfgname\\$self->{name} $self->{platform}\" />\n";
- }
- print $f <<EOF;
- </Configuration>
-EOF
- return;
-}
-
-sub WriteReferences
-{
- my ($self, $f) = @_;
- print $f " <References>\n";
- foreach my $ref (@{ $self->{references} })
- {
- print $f
- " <ProjectReference ReferencedProjectIdentifier=\"$ref->{guid}\" Name=\"$ref->{name}\" />\n";
- }
- print $f " </References>\n";
- return;
-}
-
-sub GenerateCustomTool
-{
- my ($self, $desc, $tool, $output, $cfg) = @_;
- if (!defined($cfg))
- {
- return $self->GenerateCustomTool($desc, $tool, $output, 'Debug')
- . $self->GenerateCustomTool($desc, $tool, $output, 'Release');
- }
- return
- "<FileConfiguration Name=\"$cfg|$self->{platform}\"><Tool Name=\"VCCustomBuildTool\" Description=\"$desc\" CommandLine=\"$tool\" AdditionalDependencies=\"\" Outputs=\"$output\" /></FileConfiguration>";
-}
-
-package VC2005Project;
-
-#
-# Package that encapsulates a Visual C++ 2005 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '8.00';
-
- return $self;
-}
-
-package VC2008Project;
-
-#
-# Package that encapsulates a Visual C++ 2008 project file
-#
-
-use strict;
-use warnings;
-use base qw(VCBuildProject);
-
-no warnings qw(redefine); ## no critic
-
-sub new
-{
- my $classname = shift;
- my $self = $classname->SUPER::_new(@_);
- bless($self, $classname);
-
- $self->{vcver} = '9.00';
-
- return $self;
-}
-
-1;
diff --git a/src/tools/msvc/VSObjectFactory.pm b/src/tools/msvc/VSObjectFactory.pm
index 92a4fb6841f..1a94cd866ee 100644
--- a/src/tools/msvc/VSObjectFactory.pm
+++ b/src/tools/msvc/VSObjectFactory.pm
@@ -13,7 +13,6 @@ use warnings;
use Exporter;
use Project;
use Solution;
-use VCBuildProject;
use MSBuildProject;
our (@ISA, @EXPORT);
@@ -31,23 +30,7 @@ sub CreateSolution
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '8.00')
- {
- return new VS2005Solution(@_);
- }
- elsif ($visualStudioVersion eq '9.00')
- {
- return new VS2008Solution(@_);
- }
- elsif ($visualStudioVersion eq '10.00')
- {
- return new VS2010Solution(@_);
- }
- elsif ($visualStudioVersion eq '11.00')
- {
- return new VS2012Solution(@_);
- }
- elsif ($visualStudioVersion eq '12.00')
+ if ($visualStudioVersion eq '12.00')
{
return new VS2013Solution(@_);
}
@@ -78,23 +61,7 @@ sub CreateProject
$visualStudioVersion = DetermineVisualStudioVersion();
}
- if ($visualStudioVersion eq '8.00')
- {
- return new VC2005Project(@_);
- }
- elsif ($visualStudioVersion eq '9.00')
- {
- return new VC2008Project(@_);
- }
- elsif ($visualStudioVersion eq '10.00')
- {
- return new VC2010Project(@_);
- }
- elsif ($visualStudioVersion eq '11.00')
- {
- return new VC2012Project(@_);
- }
- elsif ($visualStudioVersion eq '12.00')
+ if ($visualStudioVersion eq '12.00')
{
return new VC2013Project(@_);
}
diff --git a/src/tools/msvc/build.pl b/src/tools/msvc/build.pl
index 9a234d1cc25..35649fe5a24 100644
--- a/src/tools/msvc/build.pl
+++ b/src/tools/msvc/build.pl
@@ -53,16 +53,12 @@ elsif (uc($ARGV[0]) ne "RELEASE")
# ... and do it
-if ($buildwhat and $vcver >= 10.00)
+if ($buildwhat)
{
system(
"msbuild $buildwhat.vcxproj /verbosity:normal $msbflags /p:Configuration=$bconf"
);
}
-elsif ($buildwhat)
-{
- system("vcbuild $msbflags $buildwhat.vcproj $bconf");
-}
else
{
system(
--
2.18.0.rc2.dirty
[text/x-diff] v2-0002-Introduce-minimal-C99-usage-to-verify-compiler-su.patch (5.0K, ../../20180823013134.3h4j62eeiaibpgvo@alap3.anarazel.de/3-v2-0002-Introduce-minimal-C99-usage-to-verify-compiler-su.patch)
download | inline diff:
From 15832a329d9f9bbeb6c31d916fd0b3d6f412c0f2 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:44:33 -0700
Subject: [PATCH v2 2/4] Introduce minimal C99 usage to verify compiler
support.
This just converts a few for loops in postgres.c to declare variables
in the loop initializer, and uses designated initializers in smgr.c's
definition of smgr callbacks.
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
src/backend/storage/smgr/smgr.c | 21 ++++++++++++++++++---
src/backend/tcop/postgres.c | 25 +++++++------------------
2 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/src/backend/storage/smgr/smgr.c b/src/backend/storage/smgr/smgr.c
index 08f06bade25..189342ef86a 100644
--- a/src/backend/storage/smgr/smgr.c
+++ b/src/backend/storage/smgr/smgr.c
@@ -67,9 +67,24 @@ typedef struct f_smgr
static const f_smgr smgrsw[] = {
/* magnetic disk */
- {mdinit, NULL, mdclose, mdcreate, mdexists, mdunlink, mdextend,
- mdprefetch, mdread, mdwrite, mdwriteback, mdnblocks, mdtruncate,
- mdimmedsync, mdpreckpt, mdsync, mdpostckpt
+ {
+ .smgr_init = mdinit,
+ .smgr_shutdown = NULL,
+ .smgr_close = mdclose,
+ .smgr_create = mdcreate,
+ .smgr_exists = mdexists,
+ .smgr_unlink = mdunlink,
+ .smgr_extend = mdextend,
+ .smgr_prefetch = mdprefetch,
+ .smgr_read = mdread,
+ .smgr_write = mdwrite,
+ .smgr_writeback = mdwriteback,
+ .smgr_nblocks = mdnblocks,
+ .smgr_truncate = mdtruncate,
+ .smgr_immedsync = mdimmedsync,
+ .smgr_pre_ckpt = mdpreckpt,
+ .smgr_sync = mdsync,
+ .smgr_post_ckpt = mdpostckpt
}
};
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 07b956553a7..7a9ada2c719 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -1310,7 +1310,6 @@ exec_parse_message(const char *query_string, /* string to execute */
{
Query *query;
bool snapshot_set = false;
- int i;
raw_parse_tree = linitial_node(RawStmt, parsetree_list);
@@ -1366,7 +1365,7 @@ exec_parse_message(const char *query_string, /* string to execute */
/*
* Check all parameter types got determined.
*/
- for (i = 0; i < numParams; i++)
+ for (int i = 0; i < numParams; i++)
{
Oid ptype = paramTypes[i];
@@ -1555,10 +1554,8 @@ exec_bind_message(StringInfo input_message)
numPFormats = pq_getmsgint(input_message, 2);
if (numPFormats > 0)
{
- int i;
-
pformats = (int16 *) palloc(numPFormats * sizeof(int16));
- for (i = 0; i < numPFormats; i++)
+ for (int i = 0; i < numPFormats; i++)
pformats[i] = pq_getmsgint(input_message, 2);
}
@@ -1641,8 +1638,6 @@ exec_bind_message(StringInfo input_message)
*/
if (numParams > 0)
{
- int paramno;
-
params = (ParamListInfo) palloc(offsetof(ParamListInfoData, params) +
numParams * sizeof(ParamExternData));
/* we have static list of params, so no hooks needed */
@@ -1654,7 +1649,7 @@ exec_bind_message(StringInfo input_message)
params->parserSetupArg = NULL;
params->numParams = numParams;
- for (paramno = 0; paramno < numParams; paramno++)
+ for (int paramno = 0; paramno < numParams; paramno++)
{
Oid ptype = psrc->param_types[paramno];
int32 plength;
@@ -1782,10 +1777,8 @@ exec_bind_message(StringInfo input_message)
numRFormats = pq_getmsgint(input_message, 2);
if (numRFormats > 0)
{
- int i;
-
rformats = (int16 *) palloc(numRFormats * sizeof(int16));
- for (i = 0; i < numRFormats; i++)
+ for (int i = 0; i < numRFormats; i++)
rformats[i] = pq_getmsgint(input_message, 2);
}
@@ -2212,7 +2205,6 @@ errdetail_params(ParamListInfo params)
{
StringInfoData param_str;
MemoryContext oldcontext;
- int paramno;
/* This code doesn't support dynamic param lists */
Assert(params->paramFetch == NULL);
@@ -2222,7 +2214,7 @@ errdetail_params(ParamListInfo params)
initStringInfo(¶m_str);
- for (paramno = 0; paramno < params->numParams; paramno++)
+ for (int paramno = 0; paramno < params->numParams; paramno++)
{
ParamExternData *prm = ¶ms->params[paramno];
Oid typoutput;
@@ -2325,7 +2317,6 @@ static void
exec_describe_statement_message(const char *stmt_name)
{
CachedPlanSource *psrc;
- int i;
/*
* Start up a transaction command. (Note that this will normally change
@@ -2384,7 +2375,7 @@ exec_describe_statement_message(const char *stmt_name)
* message type */
pq_sendint16(&row_description_buf, psrc->num_params);
- for (i = 0; i < psrc->num_params; i++)
+ for (int i = 0; i < psrc->num_params; i++)
{
Oid ptype = psrc->param_types[i];
@@ -4179,10 +4170,8 @@ PostgresMain(int argc, char *argv[],
numParams = pq_getmsgint(&input_message, 2);
if (numParams > 0)
{
- int i;
-
paramTypes = (Oid *) palloc(numParams * sizeof(Oid));
- for (i = 0; i < numParams; i++)
+ for (int i = 0; i < numParams; i++)
paramTypes[i] = pq_getmsgint(&input_message, 4);
}
pq_getmsgend(&input_message);
--
2.18.0.rc2.dirty
[text/x-diff] v2-0003-Remove-test-for-VA_ARGS-implied-by-C99.patch (5.9K, ../../20180823013134.3h4j62eeiaibpgvo@alap3.anarazel.de/4-v2-0003-Remove-test-for-VA_ARGS-implied-by-C99.patch)
download | inline diff:
From 6f8acfd2c5ae1c296c8cc314ceb144beb6b353a7 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 22 Aug 2018 16:04:47 -0700
Subject: [PATCH v2 3/4] Remove test for VA_ARGS, implied by C99.
This simplifies logic / reduces duplication in a few headers.
Author: Andres Freund
Discussion: https://postgr.es/m/97d4b165-192d-3605-749c-f614a0c4e783@2ndquadrant.com
---
config/c-compiler.m4 | 19 -------------------
configure | 32 --------------------------------
configure.in | 1 -
src/include/pg_config.h.in | 3 ---
src/include/pg_config.h.win32 | 3 ---
src/include/utils/elog.h | 8 +-------
src/pl/plpython/plpy_elog.h | 4 ----
7 files changed, 1 insertion(+), 69 deletions(-)
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 67675a31bb6..eedaf12d69c 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -415,25 +415,6 @@ fi])# PGAC_C_COMPUTED_GOTO
-# PGAC_C_VA_ARGS
-# --------------
-# Check if the C compiler understands C99-style variadic macros,
-# and define HAVE__VA_ARGS if so.
-AC_DEFUN([PGAC_C_VA_ARGS],
-[AC_CACHE_CHECK(for __VA_ARGS__, pgac_cv__va_args,
-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include <stdio.h>],
-[#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-])],
-[pgac_cv__va_args=yes],
-[pgac_cv__va_args=no])])
-if test x"$pgac_cv__va_args" = xyes ; then
-AC_DEFINE(HAVE__VA_ARGS, 1,
- [Define to 1 if your compiler understands __VA_ARGS__ in macros.])
-fi])# PGAC_C_VA_ARGS
-
-
-
# PGAC_PROG_VARCC_VARFLAGS_OPT
# -----------------------
# Given a compiler, variable name and a string, check if the compiler
diff --git a/configure b/configure
index dd439ddd2f6..b143c6d6ba4 100755
--- a/configure
+++ b/configure
@@ -13962,38 +13962,6 @@ if test x"$pgac_cv_computed_goto" = xyes ; then
$as_echo "#define HAVE_COMPUTED_GOTO 1" >>confdefs.h
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __VA_ARGS__" >&5
-$as_echo_n "checking for __VA_ARGS__... " >&6; }
-if ${pgac_cv__va_args+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-#include <stdio.h>
-int
-main ()
-{
-#define debug(...) fprintf(stderr, __VA_ARGS__)
-debug("%s", "blarg");
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
- pgac_cv__va_args=yes
-else
- pgac_cv__va_args=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__va_args" >&5
-$as_echo "$pgac_cv__va_args" >&6; }
-if test x"$pgac_cv__va_args" = xyes ; then
-
-$as_echo "#define HAVE__VA_ARGS 1" >>confdefs.h
-
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether struct tm is in sys/time.h or time.h" >&5
$as_echo_n "checking whether struct tm is in sys/time.h or time.h... " >&6; }
diff --git a/configure.in b/configure.in
index 5869ab7c5bc..3280afa0dab 100644
--- a/configure.in
+++ b/configure.in
@@ -1434,7 +1434,6 @@ PGAC_C_BUILTIN_BSWAP64
PGAC_C_BUILTIN_CONSTANT_P
PGAC_C_BUILTIN_UNREACHABLE
PGAC_C_COMPUTED_GOTO
-PGAC_C_VA_ARGS
PGAC_STRUCT_TIMEZONE
PGAC_UNION_SEMUN
PGAC_STRUCT_SOCKADDR_UN
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 827574ee40d..37649d77d67 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -754,9 +754,6 @@
/* Define to 1 if your compiler understands _Static_assert. */
#undef HAVE__STATIC_ASSERT
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#undef HAVE__VA_ARGS
-
/* Define to 1 if you have the `__strtoll' function. */
#undef HAVE___STRTOLL
diff --git a/src/include/pg_config.h.win32 b/src/include/pg_config.h.win32
index 46ce49def2f..4e2bd3c1352 100644
--- a/src/include/pg_config.h.win32
+++ b/src/include/pg_config.h.win32
@@ -597,9 +597,6 @@
/* Define to 1 if your compiler understands _Static_assert. */
/* #undef HAVE__STATIC_ASSERT */
-/* Define to 1 if your compiler understands __VA_ARGS__ in macros. */
-#define HAVE__VA_ARGS 1
-
/* Define to the appropriate printf length modifier for 64-bit ints. */
#define INT64_MODIFIER "ll"
diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h
index 4350b120aab..33c6b53e278 100644
--- a/src/include/utils/elog.h
+++ b/src/include/utils/elog.h
@@ -207,9 +207,8 @@ extern int getinternalerrposition(void);
* elog(ERROR, "portal \"%s\" not found", stmt->portalname);
*----------
*/
-#ifdef HAVE__VA_ARGS
/*
- * If we have variadic macros, we can give the compiler a hint about the
+ * Using variadic macros, we can give the compiler a hint about the
* call not returning when elevel >= ERROR. See comments for ereport().
* Note that historically elog() has called elog_start (which saves errno)
* before evaluating "elevel", so we preserve that behavior here.
@@ -236,11 +235,6 @@ extern int getinternalerrposition(void);
} \
} while(0)
#endif /* HAVE__BUILTIN_CONSTANT_P */
-#else /* !HAVE__VA_ARGS */
-#define elog \
- elog_start(__FILE__, __LINE__, PG_FUNCNAME_MACRO), \
- elog_finish
-#endif /* HAVE__VA_ARGS */
extern void elog_start(const char *filename, int lineno, const char *funcname);
extern void elog_finish(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
diff --git a/src/pl/plpython/plpy_elog.h b/src/pl/plpython/plpy_elog.h
index e4b30c3cca1..b56ac412476 100644
--- a/src/pl/plpython/plpy_elog.h
+++ b/src/pl/plpython/plpy_elog.h
@@ -15,7 +15,6 @@ extern PyObject *PLy_exc_spi_error;
*
* See comments at elog() about the compiler hinting.
*/
-#ifdef HAVE__VA_ARGS
#ifdef HAVE__BUILTIN_CONSTANT_P
#define PLy_elog(elevel, ...) \
do { \
@@ -32,9 +31,6 @@ extern PyObject *PLy_exc_spi_error;
pg_unreachable(); \
} while(0)
#endif /* HAVE__BUILTIN_CONSTANT_P */
-#else /* !HAVE__VA_ARGS */
-#define PLy_elog PLy_elog_impl
-#endif /* HAVE__VA_ARGS */
extern void PLy_elog_impl(int elevel, const char *fmt,...) pg_attribute_printf(2, 3);
--
2.18.0.rc2.dirty
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-23 20:02 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 37+ messages in thread
From: Peter Eisentraut @ 2018-08-23 20:02 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 23/08/2018 03:31, Andres Freund wrote:
> On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
>> Attached is a version doing so.
>
> Mildly updated version attached. This adds an explanatory commit
> message, removes one stray docs C89 reference, and fixes a mis-squashing
> of a patch.
Let's do it!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 01:44 Andres Freund <andres@anarazel.de>
parent: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
0 siblings, 2 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-24 01:44 UTC (permalink / raw)
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:
> On 23/08/2018 03:31, Andres Freund wrote:
> > On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
> >> Attached is a version doing so.
> >
> > Mildly updated version attached. This adds an explanatory commit
> > message, removes one stray docs C89 reference, and fixes a mis-squashing
> > of a patch.
>
> Let's do it!
Pushed the first two. I'll send the presumably affected buildfarm
owners an email, asking them whether they want to update.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 02:25 Thomas Munro <thomas.munro@enterprisedb.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 37+ messages in thread
From: Thomas Munro @ 2018-08-24 02:25 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On Fri, Aug 24, 2018 at 1:44 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-08-23 22:02:26 +0200, Peter Eisentraut wrote:
>> On 23/08/2018 03:31, Andres Freund wrote:
>> > On 2018-08-22 17:09:05 -0700, Andres Freund wrote:
>> >> Attached is a version doing so.
>> >
>> > Mildly updated version attached. This adds an explanatory commit
>> > message, removes one stray docs C89 reference, and fixes a mis-squashing
>> > of a patch.
>>
>> Let's do it!
>
> Pushed the first two. I'll send the presumably affected buildfarm
> owners an email, asking them whether they want to update.
Note that designated initialisers are not in C++ yet (though IIUC they
have been accepted in P0329R4[1] for the draft that will become C++20
whatever it turns out to be).
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4691.html
--
Thomas Munro
http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 15:46 Andres Freund <andres@anarazel.de>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 2 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-24 15:46 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Hi,
On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
> Pushed the first two.
Seems to have worked like expected.
> I'll send the presumably affected buildfarm owners an email, asking
> them whether they want to update.
Did that.
Andrew, as expected my buildfarm animal mylodon, which uses compiler
flags to enforce C89 compliance, failed due to this commit:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mylodon&br=HEAD
I'd like to change it so it doesn't enforce C89 compliance across the
board, but instead enforces the relevant standard. For that I'd need to
change CFLAGS per-branch in the buildfarm. Is that possible already? Do
I need two different config files?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 16:10 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 37+ messages in thread
From: Tom Lane @ 2018-08-24 16:10 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Andres Freund <andres@anarazel.de> writes:
> I'd like to change it so it doesn't enforce C89 compliance across the
> board, but instead enforces the relevant standard. For that I'd need to
> change CFLAGS per-branch in the buildfarm. Is that possible already? Do
> I need two different config files?
I just did that on dromedary, with a stanza like this at the bottom:
if ($branch eq 'HEAD' or $branch ge 'REL_12')
{
$conf{config_env}->{CC} = 'ccache gcc -std=c99';
}
else
{
$conf{config_env}->{CC} = 'ccache gcc -ansi';
}
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 17:02 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-08-24 17:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 2018-08-24 12:10:34 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I'd like to change it so it doesn't enforce C89 compliance across the
> > board, but instead enforces the relevant standard. For that I'd need to
> > change CFLAGS per-branch in the buildfarm. Is that possible already? Do
> > I need two different config files?
>
> I just did that on dromedary, with a stanza like this at the bottom:
>
> if ($branch eq 'HEAD' or $branch ge 'REL_12')
> {
> $conf{config_env}->{CC} = 'ccache gcc -std=c99';
> }
> else
> {
> $conf{config_env}->{CC} = 'ccache gcc -ansi';
> }
Thanks, did something similar, mylodon should become green soon. I kinda
was hoping that CFLAGS would directly accept version specific like some
other vars directly...
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 18:09 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Andres Freund <andres@anarazel.de>
1 sibling, 2 replies; 37+ messages in thread
From: Andrew Dunstan @ 2018-08-24 18:09 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 08/24/2018 11:46 AM, Andres Freund wrote:
> Hi,
>
> On 2018-08-23 18:44:34 -0700, Andres Freund wrote:
>> Pushed the first two.
> Seems to have worked like expected.
>
>> I'll send the presumably affected buildfarm owners an email, asking
>> them whether they want to update.
> Did that.
I have installed VS2017 on bowerbird and a test is currently running.
It's got past the make phase so I assume everything is kosher.
However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5.
Perhaps we should consider backpatching support for those down to 9.3.
If not, I will just restrict bowerbird to building 9.6 and up. That's
fine by me, we'll still have coverage from, say, currawong, but it's a
pity we'll only be able to support the older compilers on the old branches.
>
>
> Andrew, as expected my buildfarm animal mylodon, which uses compiler
> flags to enforce C89 compliance, failed due to this commit:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mylodon&br=HEAD
>
> I'd like to change it so it doesn't enforce C89 compliance across the
> board, but instead enforces the relevant standard. For that I'd need to
> change CFLAGS per-branch in the buildfarm. Is that possible already? Do
> I need two different config files?
>
>
I saw Tom's answer, and it will work as far as it goes. But maybe we
should look at doing that in configure instead of putting the onus on
all buildfarm owners? It already knows if it's using a GNU compiler, not
sure how ubiquitous the -ansi and -std=c99 flags are.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 18:12 Andres Freund <andres@anarazel.de>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
1 sibling, 1 reply; 37+ messages in thread
From: Andres Freund @ 2018-08-24 18:12 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Hi,
On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
> I have installed VS2017 on bowerbird and a test is currently running. It's
> got past the make phase so I assume everything is kosher.
Cool, thanks.
> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
> we should consider backpatching support for those down to 9.3.
Hm, I have no strong objections to that. I don't think it's strictly
necessary, given 2013 is supported across the board, but for the non MSVC
world, we do fix compiler issues in older branches. There's not that
much code for the newer versions afaict?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 18:36 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
1 sibling, 1 reply; 37+ messages in thread
From: Tom Lane @ 2018-08-24 18:36 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Andres Freund <andres@anarazel.de>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> I saw Tom's answer, and it will work as far as it goes. But maybe we
> should look at doing that in configure instead of putting the onus on
> all buildfarm owners? It already knows if it's using a GNU compiler, not
> sure how ubiquitous the -ansi and -std=c99 flags are.
No, the only reason either of us are doing that is to force use of a
flag that's different from what configure would select by default
(which evidently is -std=gnu99 for gcc). Most buildfarm owners have
no need to do anything.
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 18:38 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 37+ messages in thread
From: Tom Lane @ 2018-08-24 18:38 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Andres Freund <andres@anarazel.de> writes:
> On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
>> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
>> we should consider backpatching support for those down to 9.3.
> Hm, I have no strong objections to that. I don't think it's strictly
> necessary, given 2013 is supported across the board, but for the non MSVC
> world, we do fix compiler issues in older branches. There's not that
> much code for the newer versions afaict?
+1 for taking a look at how big a patch it would be. But I kind of
thought we'd intentionally rejected back-patching some of those changes
to begin with, so I'm not sure the end decision will change.
regards, tom lane
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 19:10 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 37+ messages in thread
From: Andrew Dunstan @ 2018-08-24 19:10 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 08/24/2018 02:36 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> I saw Tom's answer, and it will work as far as it goes. But maybe we
>> should look at doing that in configure instead of putting the onus on
>> all buildfarm owners? It already knows if it's using a GNU compiler, not
>> sure how ubiquitous the -ansi and -std=c99 flags are.
> No, the only reason either of us are doing that is to force use of a
> flag that's different from what configure would select by default
> (which evidently is -std=gnu99 for gcc). Most buildfarm owners have
> no need to do anything.
>
>
Ah. Ok. Then your answer is good.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-08-24 19:42 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 37+ messages in thread
From: Andrew Dunstan @ 2018-08-24 19:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 08/24/2018 02:38 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
>>> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5. Perhaps
>>> we should consider backpatching support for those down to 9.3.
>> Hm, I have no strong objections to that. I don't think it's strictly
>> necessary, given 2013 is supported across the board, but for the non MSVC
>> world, we do fix compiler issues in older branches. There's not that
>> much code for the newer versions afaict?
> +1 for taking a look at how big a patch it would be. But I kind of
> thought we'd intentionally rejected back-patching some of those changes
> to begin with, so I'm not sure the end decision will change.
The VS2017 patch applies cleanly to 9.5, so that seems easy. The VS2015
patch from 9.5 needs a very small amount of adjustment by the look of it
for 9.3 and 9.4, after which I hope the VS2017 patch would again apply
cleanly.
I'll try to put this together.
The trouble with not back patching support to all live branches as new
versions come in is that it acts as a significant discouragement to
buildfarm owners to use the latest Visual Studio versions. I've never
argued stringly on this point before, but I think i'm goiung to ber
inclined to in future.
Meanwhile, I will turn bowerbird back on but just for >= 9.6 for now.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-09-11 20:13 Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 1 reply; 37+ messages in thread
From: Andrew Dunstan @ 2018-09-11 20:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; +Cc: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
On 08/24/2018 03:42 PM, Andrew Dunstan wrote:
>
>
> On 08/24/2018 02:38 PM, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2018-08-24 14:09:09 -0400, Andrew Dunstan wrote:
>>>> However, we only support VS2017 down to 9.6 and Vs2015 down to 9.5.
>>>> Perhaps
>>>> we should consider backpatching support for those down to 9.3.
>>> Hm, I have no strong objections to that. I don't think it's strictly
>>> necessary, given 2013 is supported across the board, but for the non
>>> MSVC
>>> world, we do fix compiler issues in older branches. There's not that
>>> much code for the newer versions afaict?
>> +1 for taking a look at how big a patch it would be. But I kind of
>> thought we'd intentionally rejected back-patching some of those changes
>> to begin with, so I'm not sure the end decision will change.
>
> The VS2017 patch applies cleanly to 9.5, so that seems easy. The
> VS2015 patch from 9.5 needs a very small amount of adjustment by the
> look of it for 9.3 and 9.4, after which I hope the VS2017 patch would
> again apply cleanly.
>
> I'll try to put this together.
>
> The trouble with not back patching support to all live branches as new
> versions come in is that it acts as a significant discouragement to
> buildfarm owners to use the latest Visual Studio versions. I've never
> argued stringly on this point before, but I think i'm goiung to ber
> inclined to in future.
>
> Meanwhile, I will turn bowerbird back on but just for >= 9.6 for now.
>
I've pushed support for the latest MSVC compilers back to all live branches.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 37+ messages in thread
* Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c)
@ 2018-09-11 20:27 Andres Freund <andres@anarazel.de>
parent: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
0 siblings, 0 replies; 37+ messages in thread
From: Andres Freund @ 2018-09-11 20:27 UTC (permalink / raw)
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>; Peter Eisentraut <peter.eisentraut@2ndquadrant.com>; Joshua D. Drake <jd@commandprompt.com>; Thomas Munro <thomas.munro@enterprisedb.com>; David Steele <david@pgmasters.net>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Craig Ringer <craig@2ndquadrant.com>
Hi,
On 2018-09-11 16:13:15 -0400, Andrew Dunstan wrote:
> I've pushed support for the latest MSVC compilers back to all live branches.
Thanks!
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 37+ messages in thread
end of thread, other threads:[~2018-09-11 20:27 UTC | newest]
Thread overview: 37+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-08-21 15:56 Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-08-21 17:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-21 17:31 ` Andres Freund <andres@anarazel.de>
2018-08-21 17:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-21 17:54 ` Andres Freund <andres@anarazel.de>
2018-08-21 18:03 ` Chapman Flack <chap@anastigmatix.net>
2018-08-22 10:28 ` Amit Kapila <amit.kapila16@gmail.com>
2018-08-21 18:06 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-08-21 18:09 ` Joshua D. Drake <jd@commandprompt.com>
2018-08-21 20:49 ` Andres Freund <andres@anarazel.de>
2018-08-21 21:58 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-08-21 23:29 ` Andres Freund <andres@anarazel.de>
2018-08-22 11:47 ` Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
2018-08-22 12:02 ` Andres Freund <andres@anarazel.de>
2018-08-22 12:22 ` Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
2018-08-22 14:56 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-08-22 15:01 ` Andres Freund <andres@anarazel.de>
2018-08-22 16:56 ` David Steele <david@pgmasters.net>
2018-08-23 00:09 ` Andres Freund <andres@anarazel.de>
2018-08-23 00:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-23 00:19 ` Andres Freund <andres@anarazel.de>
2018-08-23 01:31 ` Andres Freund <andres@anarazel.de>
2018-08-23 20:02 ` Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2018-08-24 01:44 ` Andres Freund <andres@anarazel.de>
2018-08-24 02:25 ` Thomas Munro <thomas.munro@enterprisedb.com>
2018-08-24 15:46 ` Andres Freund <andres@anarazel.de>
2018-08-24 16:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-24 17:02 ` Andres Freund <andres@anarazel.de>
2018-08-24 18:09 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-08-24 18:12 ` Andres Freund <andres@anarazel.de>
2018-08-24 18:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-24 19:42 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-09-11 20:13 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-09-11 20:27 ` Andres Freund <andres@anarazel.de>
2018-08-24 18:36 ` Tom Lane <tgl@sss.pgh.pa.us>
2018-08-24 19:10 ` Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
2018-08-21 18:10 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox