Re: [mail] Re: Win32 port patches submitted

Mingw and mingw-ported tools ? That's a nice small and cozy unix-like
envoronment on tom of Windows. Add it emacs, and windoww becomes almost
tolerable ...

Emmanuel Charpentier

[ Back to lurking ... ]

Brian Bruns wrote:
> Problem is, nobody builds packages on windows anyway. They just all
> download the binary a guy (usually literally "one guy") built. So, let's
> just make sure that one guy has cygwin loaded on his machine and we'll be
> all set. </tougue in cheek>
>
> Sorry, couldn't help myself...Seriously, it's a cultural thing, I wouldn't
> plan on a mighty hoard of windows database developers who are put off by
> loading cygwin. I do wonder what the requirements are for building
> commercial db's that run on unix and windows. I imagine they are
> similarly off-putting if it were an option.
>
>
> On Tue, 21 Jan 2003, Al Sutton wrote:
>
>
>>I would back keeping the windows specific files, and if anything moving the
>>code away from using the UNIX like programs. My reasoning is that the more
>>unix tools you use for compiling, the less likley you are to attract
>>existing windows-only developers to work on the code. I see the Win32 patch
>>as a great oppertunity to attract more eyes to the code, and don't want the
>>oppertunity to be lost because of the build requirements.
>>
>>Al.
>>
>>----- Original Message -----
>>From: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
>>To: "Jan Wieck" <JanWieck(at)Yahoo(dot)com>
>>Cc: "Postgres development" <pgsql-hackers(at)postgresql(dot)org>
>>Sent: Tuesday, January 21, 2003 5:40 PM
>>Subject: [mail] Re: [HACKERS] Win32 port patches submitted
>>
>>
>>
>>>Jan Wieck writes:
>>>
>>>
>>>>I just submitted the patches for the native Win32 port of v7.2.1 on the
>>>>patches mailing list.
>>>
>>>I'm concerned that you are adding all these *.dsp files for build process
>>>control. This is going to be a burden to maintain. Everytime someone
>>>changes an aspect of how a file is built the Windows port needs to be
>>>fixed. And since the tool that operates on these files is probably not
>>>freely available this will be difficult. I don't see a strong reason not
>>>to stick with good old configure; make; make install. You're already
>>>requiring various Unix-like tools, so you might as well require the full
>>>shell environment. A lot of the porting aspects such as substitute
>>>implemenations of the C library functions could be handled nearly for free
>>>using the existing infrastructure and this whole patch would become much
>>>less intimidating.
>>>
>>>--
>>>Peter Eisentraut peter_e(at)gmx(dot)net
>>>
>>>
>>>---------------------------(end of broadcast)---------------------------
>>>TIP 5: Have you checked our extensive FAQ?
>>>
>>>http://www.postgresql.org/users-lounge/docs/faq.html
>>>
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 5: Have you checked our extensive FAQ?
>>
>>http://www.postgresql.org/users-lounge/docs/faq.html
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)