Re: [HACKERS] Win32 port patches submitted
Peter Eisentraut wrote: Justin Clift writes: The advantages to having the Win32 port be natively compatible with Visual Studio is that it already is (no toolset-porting work needed there), You're missing a couple of points here. First, the MS Visual whatever compiler can also be used with a makefile-driven build system. Second, the port as it stands isn't really compatible with anything except Jan's build instructions. There's a lot of work to be done before we get anything that builds out of the box in the 7.4 branch, and it's going to be a lot easier if we do it using the build system we already have and know. Absolutely right, I know that the build environment is more a mess than an environment. All I said is that we have a stable, working, native Win32 PostgreSQL 7.2.1 ... And I don't care if we use MingW, Borland, Cygwin or a big blend of it all, as long as the final result can be shipped binary under the BSD license. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port patches submitted
-Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 11:47 AM To: Peter Eisentraut Cc: Justin Clift; Hannu Krosing; Bruce Momjian; Tom Lane; Postgres development Subject: Re: [HACKERS] Win32 port patches submitted Peter Eisentraut wrote: Justin Clift writes: The advantages to having the Win32 port be natively compatible with Visual Studio is that it already is (no toolset-porting work needed there), You're missing a couple of points here. First, the MS Visual whatever compiler can also be used with a makefile-driven build system. Second, the port as it stands isn't really compatible with anything except Jan's build instructions. There's a lot of work to be done before we get anything that builds out of the box in the 7.4 branch, and it's going to be a lot easier if we do it using the build system we already have and know. Absolutely right, I know that the build environment is more a mess than an environment. All I said is that we have a stable, working, native Win32 PostgreSQL 7.2.1 ... And I don't care if we use MingW, Borland, Cygwin or a big blend of it all, as long as the final result can be shipped binary under the BSD license. It would be very nice if we could drive the whole thing under Mingw. It has an environment that the current developers will be familiar with (bash, ksh, GCC, etc.) and probably some scripts could perform all the manual operations. Is there a place I can download the current patched tree? I might look at automating the process to some degree. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port patches submitted
Bruce Momjian writes: I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. I don't believe that quite yet. Jan said the regression test script crashes Cygwin's bash, but how come it has never crashed anyone else's Cygwin bash? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Win32 port patches submitted
Peter Eisentraut wrote: Justin Clift writes: The advantages to having the Win32 port be natively compatible with Visual Studio is that it already is (no toolset-porting work needed there), You're missing a couple of points here. First, the MS Visual whatever compiler can also be used with a makefile-driven build system. Second, the port as it stands isn't really compatible with anything except Jan's build instructions. There's a lot of work to be done before we get anything that builds out of the box in the 7.4 branch, and it's going to be a lot easier if we do it using the build system we already have and know. Thanks Peter. Really didn't know that MS Visual things could work with makefile driven build systems, nor that the PeerDirect build process was so... unique. :) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port patches submitted
Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: 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. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. IIRC mingw tools had win-native (cygwin-less) bash at http://sourceforge.net/projects/mingw/ -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Win32 port patches submitted
Hannu Krosing wrote: Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: 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. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. IIRC mingw tools had win-native (cygwin-less) bash at http://sourceforge.net/projects/mingw/ Have been watching this ongoing conversation and am in two frames of mind about: + There are a lot of people on Win32 that are using MS Visual C or Visual Studio + There are a few fairly well established Win32 programming IDE's that are compatible with cygwin/mingw32 The advantages to having the Win32 port be natively compatible with Visual Studio is that it already is (no toolset-porting work needed there), but the disadvantage is that not just any Win32 user-with-an-interest can download it any try it out. So... that kind of excludes it somewhat (Universities/colleges might have a problem too). The advantages of having the Win32 port be natively compatible with gcc/cygwin/something is that once it's converted to that toolchain, it might be a lot less maintenance on us, as that's the toolset we use for the Unix builds. As a thought, the open source Dev-C++ IDE (Win32 and Linux) works with gcc/cygwin/mingw32 and is pretty popular. Just checked it's homepage on SourceForge (http://sourceforge.net/projects/dev-cpp/) and it's download figures are pretty large. Since March 2002 (less than 1 year ago), it's been downloaded about 120,000,000 times. Wow. 120 Million downloads in less than 1 year. That's a pretty popular IDE (16th most popular project on SourceForge) Anyway, as a thought, my vote would be to make the Win32 port work in with our toolchain or very similar (cygwin/mingw32/etc) if possible, so we don't have to rely on people having Visual C. In developing countries too, it's going to be much easier for people to get a hold of things like Dev-C++ into the future as well. Hope this provides a useful set of thoughts. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Win32 port patches submitted
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: 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. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. I don't mind Cygwin if we don't have licensing problems with distributing a Win32 binary that used Cygwin to build. I do have a problem with MKS toolkit, which is a commerical purchase. I would like to avoid reliance on that, though Jan said he needed their bash. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Windows Build System was: [HACKERS] Win32 port patches submitted
Curtis Faith wrote: tom lane writes: You think we should drive away our existing unix developers in the mere hope of attracting windows developers? Sorry, it isn't going to happen. Tom brings up a good point, that changes to support Windows should not add to the tasks of those who are doing the bulk of the work on Unixen. I don't think, however, that this necessarily means that having Windows developers use Cygwin is the right solution. We need to come up with a way to support Windows Visual C++ projects without adding work to the other developers. [...] IMHO, having a native port without native (read Visual C++) project support is a a huge missed opportunity. Perhaps. On the other hand, it may be much more work than it's worth. See below. The Visual C++ environment does not require dependency specification, it builds dependency trees by keeping track of the #include files used during preprocessing. Because of this, it should be possible to: A) Write a script/tool that reads the input files from Unix makefiles to build a list of the files in PostgreSQL and place them in appropriate projects. or alternately: B) A script/tool that recurses the directories and does the same sort of thing. There could be some sort of mapping between directories and projects in Visual C++. This may be necessary, but I seriously doubt it's anywhere close to sufficient. Right now, the Unix build relies on GNU autoconf to generate the Makefiles and many other files (even include files). And it doesn't just look for system-specific features and whatnot: it's the means by which features are selected at build time (such as SSL support, Kerberos support, which langauges to build runtime support for, etc.). To use it requires a Unix shell and a bunch of command line tools (e.g., sed). That's why Cygwin is required right now. Somehow *all* of that has to either be replaced, or someone has to decide which features will be built by all developers, or someone has to do all the legwork of making the Windows source tree roughly as configurable as the Unix one is. Doesn't sound like a terribly small task to me, though it might not be too bad for someone who has a lot of experience on both platforms. Since I don't have any real experience doing development under Windows, I'm not one to really say. But I thought you should at least know what you're up against. I do agree that being able to build and debug PostgreSQL using whichever tools are most commonly used amongst Windows developers would be desirable, perhaps very much so... -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Windows Build System was: [HACKERS] Win32 port patches submitted
tom lane writes: You think we should drive away our existing unix developers in the mere hope of attracting windows developers? Sorry, it isn't going to happen. Tom brings up a good point, that changes to support Windows should not add to the tasks of those who are doing the bulk of the work on Unixen. I don't think, however, that this necessarily means that having Windows developers use Cygwin is the right solution. We need to come up with a way to support Windows Visual C++ projects without adding work to the other developers. I believe this is possible and have outlined some ways at the end, but first some rationale: One of the biggest benefits to Open Source projects is the ability to get in there and debug/fix problems using the source. PostgreSQL will lose out to lesser DBs if there is no easy way to build and DEBUG the source on Windows. This is true whether one admits that Windows sucks or not. A developer faced with the decision of choosing: A) a system that has a native Windows Visual C++ project that runs and compiles the release with no work. B) a system that requires learning a new way of building, new tools, new who knows what else. will always choose A unless there is a very compelling reason to choose B. There are plenty of reasons a clever (or even not so clever) Windows developer can use to justify using MySQL or another open source DB instead of PostgreSQL. It is a bit harder for the neophyte to find and believe the compelling reasons to use PostgreSQL. We need to make it easier to choose PostgreSQL not harder. Think about it from this perspective. How many of you would even think about working on a project if it required that you stop using your favorite toolset, gmake? EMACS? grep? shell scripts? etc.? Professional developers spend years honing their skills. Learning the proper use of the tools involved is a very big part of the process. IMHO, having a native port without native (read Visual C++) project support is a a huge missed opportunity. Further, lack of Windows project files implies that PostgreSQL just a Unix port and that the Windows support is immature, whether the code is well supported or not. POSSIBLE SOLUTIONS: The Visual C++ Workspaces and Projects files are actually text files that have a defined format. I don't think the format is published but it looks pretty easy to figure out. The Visual C++ environment does not require dependency specification, it builds dependency trees by keeping track of the #include files used during preprocessing. Because of this, it should be possible to: A) Write a script/tool that reads the input files from Unix makefiles to build a list of the files in PostgreSQL and place them in appropriate projects. or alternately: B) A script/tool that recurses the directories and does the same sort of thing. There could be some sort of mapping between directories and projects in Visual C++. In short, for most organizations being able to easily build using the source is a prerequisite for USING an open source database, not just for being part of the DEVELOPMENT effort. -Curtis P.S. I speak from personal experience, I would have been able to help out a lot more if I didn't have to spend 90% of my time working with PostgreSQL learning Unix (or relearning) and gnu tool issues. I don't personally mind so much because I wanted to learn it better anyway, but it has definitely limited my ability to help, so far. This is especially true since I don't have the opportunity to immerse myself in Unix/PostgreSQL for days at a time and suffer from significant switching costs. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Win32 port patches submitted
On Wednesday 22 January 2003 02:01, Dann Corbit wrote: Maybe because most of the machines in the world (by a titanic landslide) are Windoze boxes. On the desktop, yes. On the server, no. PostgreSQL is nore intended for a server, no? I can see the utility in having a development installation on a Win32 box, though. people to do it. Usually Open Source guys run *NIX Taken a poll lately? If Microsoft has its way there won't be any Open Source on Windows. Well, PostgreSQL might squeak by due to the BSD license, but other licenses aren't so fortunate, and GPL is anathema to Microsoft. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port patches submitted
Jan Wieck writes: We focused on porting the programs. The goal was to have PostgreSQL running native on Win32 for a user. Having a nice and easy maintainable cross platform config, build and test environment for the developers is definitely something that still needs to be done (hint, hint). I have prepared a little patch that makes room for a native Windows build in our existing build framework. The Cygwin port would be renamed to cygwin and the new port takes over the win name. I have prepared the port specific template and makefile and extracted the dynaloader from your patch, so that you can at least run configure under Cygwin or MinGW successfully. Then I suggest we merge in the obvious parts of your patch, especially the renaming of various token constants, the shmem implementation, some library function reimplementations. In some cases I would like a bit more abstraction so that we don't have so many #ifdef's. (For example, we could have a IsAbsolutePath() that works magically for all platforms.) Then there are the hairy pieces. You add a bunch of command-line options that interact in puzzling way to communicate information about the fake fork. I think some of these are redundant, but it's hard to tell. The reimplementation of various shell scripts in C is something that would be a good idea on Unix as well for a number of reasons. Unfortunately, the ones you wrote have no chance of compiling under Unix, so we'll have to do it again. But that can happen in parallel to the other stuff. Two quick questions: Why PG_WIN32 and not just WIN32? Can the ConsoleApp thing be written in C so we don't have to get an extra C++ compiler for one file (for those who don't want to use the Microsoft toolchain)? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Win32 port patches submitted
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 [EMAIL PROTECTED] To: Jan Wieck [EMAIL PROTECTED] Cc: Postgres development [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ---(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 [EMAIL PROTECTED])
Re: [HACKERS] Win32 port patches submitted
Peter Eisentraut [EMAIL PROTECTED] writes: 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. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port patches submitted
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: 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. Indeed. I think the goal here is to have a port that *runs* in native Windows; but I see no reason not to require Cygwin for *building* it. Agreed. We focused on porting the programs. The goal was to have PostgreSQL running native on Win32 for a user. Having a nice and easy maintainable cross platform config, build and test environment for the developers is definitely something that still needs to be done (hint, hint). Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Win32 port patches submitted
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 [EMAIL PROTECTED] To: Jan Wieck [EMAIL PROTECTED] Cc: Postgres development [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ---(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
Re: [mail] Re: [HACKERS] Win32 port patches submitted
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. The problem is that when either side (unix developer or windows developer) wants to do anything that changes the build procedure, the other side breaks until someone makes the appropriate changes on the other build. Unless some committer is going to commit to looking over patches to dsp files and making makefile changes and vice versa or we were to require that anyone that wants to change build procedure must make both sets of changes, I'd think this is going to be a mess. And in the latter case, I think you're going to lose developers as well. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Win32 port patches submitted
Al Sutton [EMAIL PROTECTED] writes: 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. You think we should drive away our existing unix developers in the mere hope of attracting windows developers? Sorry, it isn't going to happen. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Win32 port patches submitted
Tom Lane wrote: Al Sutton [EMAIL PROTECTED] writes: 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. You think we should drive away our existing unix developers in the mere hope of attracting windows developers? Sorry, it isn't going to happen. A compromise is a solution that makes all sides equally unhappy ... so we should convert our build environment to ANT? Hey, just kidding ;-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Win32 port patches submitted
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 Correct. I wonder why we need a Windows port. I think it is more pain than sense. In case of Windows I'd rely on a binary distribution and a piece of documentation telling how the source can be built. I don't expect many people to do it. Usually Open Source guys run *NIX 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. In case of SAP DB they use a tool kit for building http://www.sapdb.org/develop/sap_db_development.htm It is truly painful to build it - even on UNIX (I haven't tried on Windows and I won't try in the future). As far as I have seen it throughs millions of compiler warnings. Regards, Hans -- *Cybertec Geschwinde u Schoenig* Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/1/913 68 09; +43/664/233 90 75 www.postgresql.at http://www.postgresql.at, cluster.postgresql.at http://cluster.postgresql.at, www.cybertec.at http://www.cybertec.at, kernel.cybertec.at http://kernel.cybertec.at ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Win32 port patches submitted
-Original Message- From: Hans-Jürgen Schönig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 10:54 PM To: Brian Bruns; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Win32 port patches submitted 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 Correct. I wonder why we need a Windows port. Maybe because most of the machines in the world (by a titanic landslide) are Windoze boxes. I think it is more pain than sense. In case of Windows I'd rely on a binary distribution and a piece of documentation telling how the source can be built. Sounds like a Windows port to me. How is this Windows build going to be created without a Windows port? I don't expect many people to do it. Usually Open Source guys run *NIX Taken a poll lately? 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. In case of SAP DB they use a tool kit for building http://www.sapdb.org/develop/sap_db_development.htm It is truly painful to build it - even on UNIX (I haven't tried on Windows and I won't try in the future). As far as I have seen it throughs millions of compiler warnings. It was simple to build. And if you don't want to build it, they have binary distributions. I have SAP/DB running on this machine (along with SQL*Server, PostgreSQL, DB/2, Oracle, Firebird and a few others) SAP DB is or can be used for SAP (basically, it's a port of Adabas). That makes it kind of important, for obvious reasons. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Win32 port patches submitted
Hi, I just submitted the patches for the native Win32 port of v7.2.1 on the patches mailing list. If you are not subscribed to the patches list you can download them from http://www.janwieck.net/win32_port Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
