Re: Is there a way to build PostgreSQL client libraries with MinGW

On Fri, Jan 21, 2011 at 16:24, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> 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.

That's certainly a reasonable argument. And I don't mind supporting a
complete build env for it either - as long as *I* don't have to do it.
And you seem to be doing a good job at 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.

Definitely agreed - as long as it doesn't mean we have to avoid adding
useful features because a specific compiler/env can't deal with it.
Which we've been reasonably able to avoid so far.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/