On Tue, Apr 11, 2017 at 04:51:03PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> Yeah, very long ago. A quick search of our archives shows that the number
> of mentions of Borland pretty much fell off a cliff after 2009 (excluding
> the repeated conversations about dropping support, that is).
Bruce Momjian writes:
> I am fine with removing things, but I do remember one reason the Borland
> part was kept is that some tool would only work with the
> Borland-compiled library, not gcc or MSVC, but that was long ago.
Yeah, very long ago. A quick search of our archives shows that the numbe
On Tue, Apr 11, 2017 at 03:14:23PM +0200, Magnus Hagander wrote:
> On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier
> wrote:
>
> On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote:
> > Magnus Hagander writes:
> > Are these votes for getting rid of both win32.mak and bcc32.mak?
>
On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier
wrote:
> On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote:
> > Magnus Hagander writes:
> > Are these votes for getting rid of both win32.mak and bcc32.mak?
> >
> >> PFA a patch that does this. Did I miss something? :)
> >
> > Perhaps we should
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote:
> Magnus Hagander writes:
> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
>> PFA a patch that does this. Did I miss something? :)
>
> Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
> given this patc
Magnus Hagander writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
> PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef
On Mon, Apr 10, 2017 at 2:07 PM, Michael Paquier
wrote:
> On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> Are these votes for getting rid of both win32.mak and bcc32.mak?
> >
> > I'm for it.
>
> +1.
>
PFA a patch that does this. Did I miss something? :)
--
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
> I'm for it.
+1.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Magnus Hagander writes:
> Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
> If so, count me in for the same :) Want me to do the honors, as it's my
> fault they're in there in the first place?
Sure.
regards, tom lane
--
Sent via pgsql-hac
On Fri, Apr 7, 2017 at 4:03 PM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 04/07/2017 09:58 AM, Tom Lane wrote:
> >> This seems be the same as the 2nd error that was reported back in 2013:
> >> https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%
> 3DvUK2zpjowTkzUS
On 2017-04-07 13:00:39 +0200, Magnus Hagander wrote:
> Insurmountable, probably not. The big difference is that you don't need
> *any* dependencies to build a libpq using win32.mak, but you need many of
> them (to start with, perl...) to build using the built-in one. For people
> who want to build
On 04/07/2017 09:58 AM, Tom Lane wrote:
>> This seems be the same as the 2nd error that was reported back in 2013:
>> https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%3DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com.
> Well, if it's been broken since (at least) 2013, and we've had
Heikki Linnakangas writes:
> I just tested it. After adding all the missing files to the makefile,
> I'm getting an error:
>> .\Release\libpq.dll.manifest : general error c1010070: Failed to load and
>> parse
>> the manifest. The system cannot find the file specified.
> This seems be the same
On 04/07/2017 02:00 PM, Magnus Hagander wrote:
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane wrote:
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with w
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
> >> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> >>> Still, it's not very clear why we need to cater for building just libpq
> >>> rather than the whole distrib
Andres Freund writes:
> On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
>> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
>>> Still, it's not very clear why we need to cater for building just libpq
>>> rather than the whole distribution, and a user of win32.mak presumably
>>> has the option
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> > Still, it's not very clear why we need to cater for building just libpq
> > rather than the whole distribution, and a user of win32.mak presumably
> > has the option to do the latter. The co
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote:
> Still, it's not very clear why we need to cater for building just libpq
> rather than the whole distribution, and a user of win32.mak presumably
> has the option to do the latter. The core argument for bcc32.mak,
> I think, is that we never did su
On 2017-04-07 00:01:01 -0400, Tom Lane wrote:
> Still, it's not very clear why we need to cater for building just libpq
> rather than the whole distribution, and a user of win32.mak presumably
> has the option to do the latter.
I think the raison d'etre for that infrastructure primarily comes from
I wrote:
> Michael Paquier writes:
>> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
>> win32.mak in src/interfaces/libpq. To put it short: those files are
>> not up to date. The code of SCRAM is in the tree for a bit of time
>> now, and should have updated those files to list
Michael Paquier writes:
> While looking at some SCRAM stuff, I have bumped into bcc32.mak and
> win32.mak in src/interfaces/libpq. To put it short: those files are
> not up to date. The code of SCRAM is in the tree for a bit of time
> now, and should have updated those files to list and clean up o
Hi all,
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has r
22 matches
Mail list logo
