Обсуждение: 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. # #================================================== JanWieck@Yahoo.com #
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
Peter Eisentraut <peter_e@gmx.net> 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
Tom Lane wrote: > > Peter Eisentraut <peter_e@gmx.net> 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. # #================================================== JanWieck@Yahoo.com #
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 >
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.
"Al Sutton" <al@alsutton.com> 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
Tom Lane wrote: > > "Al Sutton" <al@alsutton.com> 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. # #================================================== JanWieck@Yahoo.com #
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 >
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)
Emmanuel Charpentier wrote: > > 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 ... How good is the debugging support under mingW? Is it at least comparable to using gdb under unix? If not, you might find yourself all of the sudden out in cold ... Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
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>
Jan Wieck wrote:
>Emmanuel Charpentier wrote:
>
>>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 ...
>>
>
>How good is the debugging support under mingW? Is it at least comparable
>to using gdb under unix? If not, you might find yourself all of the
>sudden out in cold ...
>
gdb has been ported to mingw. There even exist some interfaces to
graphical IDEs (while I don't really care for that).
Another point : this environment is 100% free. You don't have to use
proprietary tools. This might be a point in some environments.
Emmanuel Charpentier
http://www.janwieck.net/win32_port/notes.win32-ports.txt How to compile this Win32 port 1) Requirements and 1-time settings: 1.1) Visual C++ You need VC++ 6.0 on ServicePack 5. Oooh no, not MS stuff plz :( Dev-Cpp is cool open source IDE, tha using a mingw port of gcc. http://www.bloodshed.net/ ----- Original Message ----- From: "Jan Wieck" <JanWieck@Yahoo.com> To: "Emmanuel Charpentier" <charpent@bacbuc.dyndns.org> Cc: <pgsql-hackers@postgresql.org> Sent: Wednesday, January 22, 2003 1:03 AM Subject: Re: [HACKERS] [mail] Re: Win32 port patches submitted > Emmanuel Charpentier wrote: > > > > 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 ... > > How good is the debugging support under mingW? Is it at least comparable > to using gdb under unix? If not, you might find yourself all of the > sudden out in cold ... > Jan
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.
On Wed, 2003-01-22 at 15:34, 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. Does anyone know how MySQL and interbase/firebird do it ? > 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. will probably change between releases (also I dont think you can easily compile C source on a C# compiler) ;/ -- Hannu Krosing <hannu@tm.ee>
I (Curtis Faith) previously wrote: > > 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. Hannu Krosing replied: > will probably change between releases Even if the format changes, the environment always has a converter that updates the project and workspace files to the new format. In other words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. The format is mostly a bunch of options specifications (which wouldn't get touched) followed by a set of named groups of source files. Even if the overall format changes, it will be much more likely to change in the specifications rather than the way lists of source file formats are specified. A conversion tool, call it BuildWindowsProjectFile, would only need to: 1) Read in the template file (containing all the options specifications and Visual C++ speficic stuff, debug and release target options, libraries to link in, etc.) This part might change with new versions of the IDE and would be manually created by someone with Visual C++ experience. 2) Read in the postgreSQL group/directory map, or alternately just mirror the groups with the directories. 3) Output the files from the PostgreSQL directories in the appropriate grouping according to the project format into the appropriate space in the template. An excerpt of the format follows: # Begin Group "Access" # Begin Group "Common" # PROP Default_Filter "cpp;c;cxx" # Begin Source File SOURCE=.\access\common\heaptuple.c # End Source File # Begin Source File SOURCE=.access\common\indextuple.c # End Source File ... other files in access\common go here # End Group # Begin Group "Index" # PROP Default_Filter "cpp;c;cxx" # Begin Source File SOURCE=.\access\index\genam.c # End Source File # Begin Source File SOURCE=.access\index\indexam.c # End Source File ... other files in access\index go here # End Group # End Group As you can see, this is a really simple format, and the direct folder/group mapping to PostgreSQL directory is pretty natural and probably the way to go. Using the approach I outline, it should be possible to have the Unix make system automatically run the BuildWindowsProjectFile tool whenever any makefile changes so the Windows projects would stay up to date without additional work for Unix developers. Hannu Krosing also wrote: > (also I dont think you can easily compile C source on a > C# compiler) ;/ I don't think it makes much sense target a compiler that won't compile the source, therefore, if what you say is true, we shouldn't bother with targeting C#. - Curtis
This is a multi-part message in MIME format.
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 peter_e@gmx.net
Hannu Krosing asked: > Does anyone know how MySQL and interbase/firebird do it ? > From the MySQL web site for version 4.0: "The Windows binaries use the Cygwin library. Source code for the version of Cygwin we have used is available on this page." I think this offers a very big opportunity to differentiate. If we had project support it would make PostgreSQL a more natural choice for Windows developers. Even in a shop that uses Unix servers with Windows front-ends, having a database server that runs on your own machine makes it much easier to debug, write code on airplanes, etc. - Curtis
Firebird uses a set of Borland command line tools and Borland's make, which they give away as a free download. Even if you're compiling for Windows, the build process uses Borland's command line "make". A batch build script copies makefiles from a single source directory and spreads them around the tree, then kicks off Borland's make. For things to work successfully, you must download Borland's tools and install them together with setting a few environment variables by hand. Borland command line tools are just a set of Unix utilities like grep, sed, make, (sh?) etc. Once upon a time they required cygwin utilities, but managed to purge themselves of cygwin with the Borland utilities. When they required cygwin, they also required some Borland utilities anyway. So they had a real reason for purging cygwin. If someone thinks the cygwin package is too big, we could require the Borland utilities instead :) For my 2 cents, I would say the project files should be a separate download. Let someone build, test, and contribute them for particular versions of PostgreSQL. I would only try to make the Visual Studio files work on true releases. I would _not_ try to keep them updated in CVS or build them on the fly. W3.org's libwww does it something like this. bbaker
On Wed, Jan 22, 2003 at 02:55:34PM -0400, Curtis Faith wrote: > > Hannu Krosing also wrote: > > (also I dont think you can easily compile C source on a > > C# compiler) ;/ > > I don't think it makes much sense target a compiler that won't compile > the source, therefore, if what you say is true, we shouldn't bother with > targeting C#. I don't think that compiling on a C# compiler is possible at all. C# is too different from C. In fact, the C# language is much more similar to Java than C/C++ ( there are no pointers, for example ). -- Adrian Maier (am@fx.ro, 40 723.002.097)
On Wednesday 22 January 2003 20:47, bbaker@priefert.com wrote: > Firebird uses a set of Borland command line tools and Borland's make, > which they give away as a free download. Even if you're compiling for > Windows, the build process uses Borland's command line "make". A batch > build script copies makefiles from a single source directory and spreads > them around the tree, then kicks off Borland's make. For things to work > successfully, you must download Borland's tools and install them > together with setting a few environment variables by hand. Borland > command line tools are just a set of Unix utilities like grep, sed, > make, (sh?) etc. Once upon a time they required cygwin utilities, but > managed to purge themselves of cygwin with the Borland utilities. When > they required cygwin, they also required some Borland utilities anyway. > So they had a real reason for purging cygwin. If someone thinks the > cygwin package is too big, we could require the Borland utilities instead > :) >I can't agree more ! Even if You do not want to hear my opinion here it is: The reason why I started to use PosgreSQL was:1. Price 2. Most features that I used on MSSQL was there (except replication). If You require MS Visual C for building, it may increase the price. Borland C++ free version 5.5 you can download from :http://www.borland.com/products/downloads/download_cbuilder.html (I newer downloaded it from there, because I got it on some CD from our local computer news). What is included in the package you can see at :http://community.borland.com/article/0,1410,21205,00.html I can point to one more example of using bcc32 in multiplatform projects:http://www.trolltech.com/products/qt/windows.html (They support also Microsoft Visual C++, but Windows version is not free !)And in the end, the developers for windows arenot stupid, they can survive without MS projects, workspaces, fancy GUI e.t.c. (at least developers that You want to contribute to Postgres.)
Curtis Faith wrote: > > 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. Hannu Krosing wrote: > will probably change between releases Even if the format changes, the environment always has a converter that updates the project and workspace files to the new format. In other words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. The format is mostly a bunch of options specifications (which wouldn't get touched) followed by a set of named groups of source files. Even if the overall format changes, it will be much more likely to change in the specifications rather than the way lists of source file formats are specified. A conversion script would only need to: 1) Read in the template file (containing all the options specifications and Visual C++ speficic stuff, debug and release target options, libraries to link in, etc.) This part might change with new versions of the IDE and would be manually created by someone with Visual C++ experience. 2) Read in the postgreSQL group/directory map, or alternately just mirror the groups with the directories. 3) Output the files from the PostgreSQL directories in the appropriate grouping according to the project format into the appropriate space in the template. An excerpt of the format follows: # Begin Group "Access" # Begin Group "Common" # PROP Default_Filter "cpp;c;cxx" # Begin Source File SOURCE=.\access\common\heaptuple.c # End Source File # Begin Source File SOURCE=.access\common\indextuple.c # End Source File ... other files in access\common go here # End Group # Begin Group "Index" # PROP Default_Filter "cpp;c;cxx" # Begin Source File SOURCE=.\access\index\genam.c # End Source File # Begin Source File SOURCE=.access\index\indexam.c # End Source File ... other files in access\index go here # End Group # End Group As you can see, this is a really easy format, and the folder/group mapping with directories is pretty natural and probably the way to go. Using the approach I outline, it should be possible to have the Unix make system automatically run the BuildWindowsProjectFile tool whenever any makefile changes so the Windows projects would stay up to date without additional work for Unix developers. Hannu Krosing also wrote: > (also I dont think you can easily compile C source on a > C# compiler) ;/ I don't think it makes much sense target a compiler that won't compile the source, therefore, if what you say is true, we shouldn't bother with targeting C#. Why does this matter? I didn't propose targeting Visual C#.NET. - Curtis
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 kevin@sysexperts.com
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> 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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: > Tom Lane wrote: > > Peter Eisentraut <peter_e@gmx.net> 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 <hannu@tm.ee>
Hannu Krosing wrote: > Bruce Momjian kirjutas P, 26.01.2003 kell 05:07: > >>Tom Lane wrote: >> >>>Peter Eisentraut <peter_e@gmx.net> 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
Justin Clift wrote: <snip> > 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) Arrrgh. Thought that sounded a bit too high. Wrong column, it's actually only about 2 million times, not 120 million. Should probably get more sleep. ;-) Sorry about that guys. 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
Are there no already-written converters from Makefile to VC project files? --------------------------------------------------------------------------- Curtis Faith wrote: > I (Curtis Faith) previously wrote: > > > 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. > > Hannu Krosing replied: > > will probably change between releases > > Even if the format changes, the environment always has a converter that > updates the project and workspace files to the new format. In other > words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. > > The format is mostly a bunch of options specifications (which wouldn't > get touched) followed by a set of named groups of source files. Even if > the overall format changes, it will be much more likely to change in the > specifications rather than the way lists of source file formats are > specified. > > A conversion tool, call it BuildWindowsProjectFile, would only need to: > > 1) Read in the template file (containing all the options specifications > and Visual C++ speficic stuff, debug and release target options, > libraries to link in, etc.) This part might change with new versions of > the IDE and would be manually created by someone with Visual C++ > experience. > > 2) Read in the postgreSQL group/directory map, or alternately just > mirror the groups with the directories. > > 3) Output the files from the PostgreSQL directories in the appropriate > grouping according to the project format into the appropriate space in > the template. > > An excerpt of the format follows: > > # Begin Group "Access" > # Begin Group "Common" > # PROP Default_Filter "cpp;c;cxx" > # Begin Source File > > SOURCE=.\access\common\heaptuple.c > # End Source File > # Begin Source File > > SOURCE=.access\common\indextuple.c > # End Source File > > ... other files in access\common go here > # End Group > > # Begin Group "Index" > > # PROP Default_Filter "cpp;c;cxx" > # Begin Source File > > SOURCE=.\access\index\genam.c > # End Source File > # Begin Source File > > SOURCE=.access\index\indexam.c > # End Source File > > ... other files in access\index go here > # End Group > > # End Group > > > As you can see, this is a really simple format, and the direct > folder/group mapping to PostgreSQL directory is pretty natural and > probably the way to go. > > Using the approach I outline, it should be possible to have the Unix > make system automatically run the BuildWindowsProjectFile tool whenever > any makefile changes so the Windows projects would stay up to date > without additional work for Unix developers. > > Hannu Krosing also wrote: > > (also I dont think you can easily compile C source on a > > C# compiler) ;/ > > I don't think it makes much sense target a compiler that won't compile > the source, therefore, if what you say is true, we shouldn't bother with > targeting C#. > > - Curtis > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Theres a script at http://ptolemy.eecs.berkeley.edu/other/makevcgen which may work, I've not tried it, but someone may want to give it a spin. Combining it with the software at http://unxutils.sourceforge.net could give us a MS build environment which only relies on installation support programs rather than relying on the installation and use of the whole Cygwin environment for the build process. Al. ----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: "Curtis Faith" <curtis@galtair.com> Cc: <pgsql-hackers@postgresql.org> Sent: Monday, January 27, 2003 12:57 AM Subject: [mail] Re: [HACKERS] Windows Build System > > Are there no already-written converters from Makefile to VC project > files? > > -------------------------------------------------------------------------- - > > Curtis Faith wrote: > > I (Curtis Faith) previously wrote: > > > > 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. > > > > Hannu Krosing replied: > > > will probably change between releases > > > > Even if the format changes, the environment always has a converter that > > updates the project and workspace files to the new format. In other > > words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc. > > > > The format is mostly a bunch of options specifications (which wouldn't > > get touched) followed by a set of named groups of source files. Even if > > the overall format changes, it will be much more likely to change in the > > specifications rather than the way lists of source file formats are > > specified. > > > > A conversion tool, call it BuildWindowsProjectFile, would only need to: > > > > 1) Read in the template file (containing all the options specifications > > and Visual C++ speficic stuff, debug and release target options, > > libraries to link in, etc.) This part might change with new versions of > > the IDE and would be manually created by someone with Visual C++ > > experience. > > > > 2) Read in the postgreSQL group/directory map, or alternately just > > mirror the groups with the directories. > > > > 3) Output the files from the PostgreSQL directories in the appropriate > > grouping according to the project format into the appropriate space in > > the template. > > > > An excerpt of the format follows: > > > > # Begin Group "Access" > > # Begin Group "Common" > > # PROP Default_Filter "cpp;c;cxx" > > # Begin Source File > > > > SOURCE=.\access\common\heaptuple.c > > # End Source File > > # Begin Source File > > > > SOURCE=.access\common\indextuple.c > > # End Source File > > > > ... other files in access\common go here > > # End Group > > > > # Begin Group "Index" > > > > # PROP Default_Filter "cpp;c;cxx" > > # Begin Source File > > > > SOURCE=.\access\index\genam.c > > # End Source File > > # Begin Source File > > > > SOURCE=.access\index\indexam.c > > # End Source File > > > > ... other files in access\index go here > > # End Group > > > > # End Group > > > > > > As you can see, this is a really simple format, and the direct > > folder/group mapping to PostgreSQL directory is pretty natural and > > probably the way to go. > > > > Using the approach I outline, it should be possible to have the Unix > > make system automatically run the BuildWindowsProjectFile tool whenever > > any makefile changes so the Windows projects would stay up to date > > without additional work for Unix developers. > > > > Hannu Krosing also wrote: > > > (also I dont think you can easily compile C source on a > > > C# compiler) ;/ > > > > I don't think it makes much sense target a compiler that won't compile > > the source, therefore, if what you say is true, we shouldn't bother with > > targeting C#. > > > > - Curtis > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (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 > >
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 peter_e@gmx.net
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. -- Peter Eisentraut peter_e@gmx.net
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
On Wednesday 22 January 2003 11:49, Hannu Krosing wrote: > On Wed, 2003-01-22 at 15:34, 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. > > Does anyone know how MySQL and interbase/firebird do it ? Xerces and Xalan from Apache both include VC6 projects. The projects are kept in their own directory apart from source code. You might want to download the Xerces and Xalan source and look at how they structured their envrionment. I *does* make it easier for Windows developers to work with VC6 projects. Alan Gutierrez - ajglist@izzy.net http://khtml-win32.sourceforge.net/ - KHTML on Windows
> ----- Original Message ----- Bruce Momjian replied > > Are there no already-written converters from Makefile to VC project > > files? The only ones I've seen convert from Unix make files to Windows NMAKE make files. This does not really do everything you want for several reasons: 1) Building with make files doesnt take advantage of the IDE for code organization, navigation and is not the kind of support that would be included for a "well supported" Windows product. 2) There is no automatic way to convert compiler options from gcc to Visual C 3) There is no way to convert the concept of different build targets (debug, release, etc.) in the way that the IDE looks at it. This is analogous but different from the way a make file handles different targets. 4) There was some discussion on the list that some features of Visual C++ were required for the port itself, something about directory replacement for include files. It is likely that this requires a special setup for the Visual C++ project which would not be easy to handle with just a NMAKE combatible make file. Al Sutton replied: > Theres a script at > http://ptolemy.eecs.berkeley.edu/other/makevcgen which may > work, I've not tried it, but someone may want to give it a spin. The script he describes here is one of the make file converters I describe above. I volunteer to write a tool in generic C to do the conversion if the approach I outlined is deemed a good solution by those that decide such things. The real question is what is the motivator for a native Windows port. If the answer is to remove CygWin dependency, that begs the further question of why is removing CygWin dependency a good idea? One of the reasons has to be that any obstacles that stand in the way of getting an implementation compiled and installed will make it less likely that developers will use it.I believe that a native Windows version that had strong Visual C++ support will win many converts from MySQL because it will make it much easier for someone who is looking for an open source database to try compiling PostgreSQL. Most people looking at open source solutions will want to at least poke around in the source and build from that source. If a developer can simply download the source, click on the Visual C++ project in the win32 directory and then build PostgreSQL, and they can see that Windows is not the "poor stepchild" because the VC project is well laid out, they will be more likely to use it for Windows projects than MySQL which requires the CygWin tools (this means "really a Unix product" to Windows developers). - Curtis
"Curtis Faith" <curtis@galtcapital.com> writes:
> If a developer can simply download the source, click on the Visual C++
> project in the win32 directory and then build PostgreSQL, and they can
> see that Windows is not the "poor stepchild" because the VC project is
> well laid out, they will be more likely to use it for Windows projects
> than MySQL which requires the CygWin tools (this means "really a Unix
> product" to Windows developers).
<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform. If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.
I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops. But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.
The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.
<flame off>
regards, tom lane
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane > Sent: Wednesday, January 29, 2003 3:37 AM > To: Curtis Faith > Cc: 'Al Sutton'; 'Bruce Momjian'; pgsql-hackers@postgresql.org > Subject: Re: [mail] Re: [HACKERS] Windows Build System > > > "Curtis Faith" <curtis@galtcapital.com> writes: > > If a developer can simply download the source, click on the Visual C++ > > project in the win32 directory and then build PostgreSQL, and they can > > see that Windows is not the "poor stepchild" because the VC project is > > well laid out, they will be more likely to use it for Windows projects > > than MySQL which requires the CygWin tools (this means "really a Unix > > product" to Windows developers). > > <flame on> > In all honesty, I do not *want* Windows people to think that they're not > running on the "poor stepchild" platform. If we go down that path, > they'll start trying to run production databases on Windows, and then > we'll get blamed for the instability of the platform, not to mention > the likelihood that it ignores Unix semantics for fsync() and suchlike > critical primitives. > > I have no objection to there being a Windows port that people can use > to do SQL-client development on their laptops. But let us please not > confuse this with an industrial-strength solution; nor give any level > of support that might lead others to make such confusion. > > The MySQL guys made the right choice here: they don't want to buy into > making Windows a grade-A platform, either. > <flame off> > > regards, tom lane Wow. I've been listening to the pros and cons for a while, and they've been really interesting. However, to assume without ever using the native Windows port that it is automatically a "poor stepchild" is unbelievable. I believe that the port, as submitted, can be used as an industrial-strength solution. I challenge you all to prove me wrong, but until you do, please lay off the assumptions. Regards, Katie Ward Principle Developer PeerDirect Corporation
On Wed, 29 Jan 2003, Katie Ward wrote: > > <flame on> > > In all honesty, I do not *want* Windows people to think that they're not > > running on the "poor stepchild" platform. If we go down that path, > > they'll start trying to run production databases on Windows, and then > > we'll get blamed for the instability of the platform, not to mention > > the likelihood that it ignores Unix semantics for fsync() and suchlike > > critical primitives. > > > > I have no objection to there being a Windows port that people can use > > to do SQL-client development on their laptops. But let us please not > > confuse this with an industrial-strength solution; nor give any level > > of support that might lead others to make such confusion. > > > > The MySQL guys made the right choice here: they don't want to buy into > > making Windows a grade-A platform, either. > > <flame off> > > > > regards, tom lane > > Wow. I've been listening to the pros and cons for a while, and they've been > really interesting. However, to assume without ever using the native > Windows port that it is automatically a "poor stepchild" is unbelievable. > > I believe that the port, as submitted, can be used as an industrial-strength > solution. I challenge you all to prove me wrong, but until you do, please > lay off the assumptions. The only assumption I see being made here is this: "I believe that the port, as submitted, can be used as an industrial-strength solution." I see no evidence to support this claim. If you have this evidence, feel free to share it with the rest of us. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio.
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. # #================================================== JanWieck@Yahoo.com #
> -----Original Message----- > From: Jan Wieck [mailto:JanWieck@Yahoo.com] > 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.
Tom Lane wrote: > "Curtis Faith" <curtis@galtcapital.com> writes: > > If a developer can simply download the source, click on the Visual C++ > > project in the win32 directory and then build PostgreSQL, and they can > > see that Windows is not the "poor stepchild" because the VC project is > > well laid out, they will be more likely to use it for Windows projects > > than MySQL which requires the CygWin tools (this means "really a Unix > > product" to Windows developers). > > <flame on> > In all honesty, I do not *want* Windows people to think that they're not > running on the "poor stepchild" platform. If we go down that path, > they'll start trying to run production databases on Windows, and then > we'll get blamed for the instability of the platform, not to mention > the likelihood that it ignores Unix semantics for fsync() and suchlike > critical primitives. Unless this concern is the result of experience (with, say, some versions of Linux or whatnot), then I'd be more inclined to take a "try it and see" attitude. I do think it's quite appropriate to make the world aware that PostgreSQL under Windows is not likely to be as dependable as PostgreSQL under other Unix platforms, if only because the underlying platform isn't as stable. The fsync() issue and others like it can hopefully be settled through testing. Frankly, I will be surprised if it doesn't work (but not *too* surprised :-). > I have no objection to there being a Windows port that people can use > to do SQL-client development on their laptops. But let us please not > confuse this with an industrial-strength solution; nor give any level > of support that might lead others to make such confusion. I don't believe the level of support this group provides has anything to do with whether or not others will regard PostgreSQL on Windows to be an industrial strength solution. Only their experience will determine that. Because PostgreSQL doesn't have a huge marketing arm, its reputation is built upon word of mouth, which is something that only comes from experience. You're assuming that if PostgreSQL is made available under Windows such that it can be run as a service, people who deploy it will immediately assume that it's an industrial strength solution. I think that assumption is faulty, because in reality people out there in the real world are reluctant to deploy PostgreSQL under *Unix* as an industrial strength solution despite its high reliability. Otherwise PostgreSQL would be a LOT more popular than it is. It takes time and experience for people to be convinced that something is industrial-strength, and the Windows port of PostgreSQL is no exception. Perhaps your real concern here is that a port of PostgreSQL to Windows might negatively impact the overall reputation of PostgreSQL due to the fragility of Windows. But I don't think that's really much of a concern: I don't believe the overall reputation of Oracle suffered due to its Windows port, for instance. I think most people who really care about such things are aware that Windows as a platform isn't as reliable as Unix and take that into account when judging the reliability of a deployed solution. For judging the reliability PostgreSQL under Windows, what would matter would be how it stacks up against other database engines running under Windows. In other words, take Windows out of the comparison equation. If PostgreSQL under Windows is at least as fast, solid, etc., as MS-SQL, DB/2, or Oracle under Windows, then people will rightly think of PostgreSQL as an industrial-strength solution and the reputation of PostgreSQL will be secure despite the failings of the platform relative to Unix. Bottom line: put tons of disclaimers about the likely reliability of the Windows port in the documentation if you'd like, but don't let these concerns prevent any action with respect to doing a proper Windows port. -- Kevin Brown kevin@sysexperts.com
Tom Lane wrote: >"Curtis Faith" <curtis@galtcapital.com> writes: > > >>If a developer can simply download the source, click on the Visual C++ >>project in the win32 directory and then build PostgreSQL, and they can >>see that Windows is not the "poor stepchild" because the VC project is >>well laid out, they will be more likely to use it for Windows projects >>than MySQL which requires the CygWin tools (this means "really a Unix >>product" to Windows developers). >> >> > ><flame on> >In all honesty, I do not *want* Windows people to think that they're not >running on the "poor stepchild" platform. If we go down that path, >they'll start trying to run production databases on Windows, and then >we'll get blamed for the instability of the platform, not to mention >the likelihood that it ignores Unix semantics for fsync() and suchlike >critical primitives. > >I have no objection to there being a Windows port that people can use >to do SQL-client development on their laptops. But let us please not >confuse this with an industrial-strength solution; nor give any level >of support that might lead others to make such confusion. > >The MySQL guys made the right choice here: they don't want to buy into >making Windows a grade-A platform, either. ><flame off> > OK, I have to weigh in here. I have been a Windows application and kernel driver developer since version 1.0. I have also worked on UNIX since the original Sun machines. Yes, the DOS version of Windows, i.e win95/98/MEis pure unmitigated crap. No doubt. The NT version of Windows, NT/2K/XP has a very well designed kernel. It is more or less based on OpenVMS. To say it is a "poor stepchild" shows a lack of imagination on your part. The NT lineage of Windows is usable as a production server. I think PostgreSQL using the most pedestrian Win32 API entry points will perform just fine. The core disk I/O subsystem and NTFS are very stable. The scheduler is not great, but is usable. The VM system is probably better than most UNIX environments, including FreeBSD and Linux. The always interruptable always reentrant device driver design could crank out some serious performance on a busy server. That being said, the kernel level GUI of Windows is a dangerous risk. Many of the changes made since the original NT (3.x) do reduce stability in a desktop environment. However, a server environment, such as PG, which does not perform any graphic interactions should be stable enough. If rebooted once a every month or two, the system should never experience data loss and windows admins are used to doing periodic reboots. One last, IMHO very important point, A LOT OF PEOPLE USE WINDOWS! Every effort should be made to support it. Yea, we all have our favorite environments. I choose Linux, others choose a *BSD, some use HPUX, Solaris or whatever. The point is a lot people choose Windows. It is possible to make a stable environment on this platform. Would I choose it? No, but some people do. Don't you think it makes sense to provide a good solution on Windows, and if they run into the inherent limitations of that platform be able to say, "Windows has some serious design flaws, but you can upgrade to Solaris or HPUX if you need" and getting the user, instead of saying, "Windows sucks, use a real platform" and losing them? I think it is a AWESOME story to say, "Build your app using PG. Start with Windows, if you like, we don't care, if you grow beyond the capabilities of Windows, just upgrade your server, no need to change anything else." Just my $0.02 Mark