答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW - Mailing list pgsql-hackers

From XiaoboGu
Subject 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW
Date
Msg-id 001201cbbb0e$6edc2ad0$4c948070$@com
Whole thread Raw
In response to Re: Is there a way to build PostgreSQL client libraries with MinGW  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW
List pgsql-hackers
Hi

I am not so familiar with the PostgreSQL development team, but using a MinGW
compatible client side is important to us, so I'd like to start doing it
myself if any of you experts can help.

Cheers

Xiaobo Gu

> -----邮件原件-----
> 发件人: Andrew Dunstan [mailto:andrew@dunslane.net]
> 发送时间: 2011年1月21日 23:25
> 收件人: Magnus Hagander
> 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org
> 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries
with MinGW
>
>
>
> On 01/21/2011 05:24 AM, Magnus Hagander wrote:
> >>
> >> That advice needs to be taken with a grain or two of salt. First, while
you
> >> probably should not use Cygwin postgres as a production server, it is
still
> >> the best way to run psql on Windows that I know of. And second, the
stuff
> > Yeah, I agree for psql the client tool (though it used to suck badly
> > if you were in a non-english locale, but they may have fixed that).
> > But not for PostgreSQL the full product. I guess we could add a
> > sentence about the client side, but it needs to be clear that the
> > non-sucky part only applies to the client.
>
>
> It's not so bad it can't be used for development, and I have known
> people who do that, and indeed I have deployed one very complex app
> developed in just that way.
>
> More importantly from my POV, there is no support in the buildfarm for
> just building the client side, and I have no intention of providing it.
> So it's not insignificant for us to be able to continue supporting a
> complete build on Cygwin, however much you dislike it.
>
>
> >
> >> about not being able to generate 64-bit binaries with Mingw is no
longer
> >> true (that's why it's no longer called Mingw32), although it is true
that
> >> nobody I know has yet tried to do so. It's on my long TODO list, and
well
> >> worth doing. (Relying on one compiler is the techno equivalent of
> >> monolingualism, which my sister's bumper sticker used to tell me is a
> >> curable condition.)
> > It's true from the perspective of *postgresql* - you can't use those
> > compiler to generate 64-bit binaries of PostgreSQL. And it's referring
> > to "these builds", not the compiler itself.
> >
> > And I'm certainly not going to stand in the way of somebody adding
> > build support for it if they (you or others) want to spend time on it
> > - that patch should just include an update to that documentation
> > paragraph, of course.
> >
> > Personally, I'm going to put what time I can put into "windows build
> > system updates" into making us work with VS 2010 because I find that
> > more important - but that's just me personally.
> >
>
>
> VS2010 is important, no doubt. But clearly there's some demand for
> continued Mingw support, hence the OP's question.
>
> As I've remarked before, I think we should support as many build
> platforms/environments as we can.
>
> cheers
>
> andrew



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Perl 5.12 complains about ecpg parser-hacking scripts
Next
From: Christian Ullrich
Date:
Subject: Re: SSPI client authentication in non-Windows builds