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@gmx.net>
>>To: "Jan Wieck" <JanWieck@Yahoo.com>
>>Cc: "Postgres development" <pgsql-hackers@postgresql.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@gmx.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@postgresql.org)