Re: 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

Here is my plan,
1. To make the configurate script pass:
Currently MinGW does not provide chmod, but on Windows I think this
can be ignored now, we all use Admin
users to do the work.
2. To make a pg-client Makefile target, can you help wich which c
files should be compiled and linked into dlls and lib file.

Xiaobo Gu

2011/1/23 XiaoboGu <guxiaobo1982(at)gmail(dot)com>:
> 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(at)dunslane(dot)net]
>> 发送时间: 2011年1月21日 23:25
>> 收件人: Magnus Hagander
>> 抄送: Robert Haas; XiaoboGu; pgsql-hackers(at)postgresql(dot)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
>
>