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
On Wednesday 22 January 2003 20:47, [EMAIL PROTECTED] 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 are not stupid, they can survive without MS projects, workspaces, fancy GUI e.t.c. (at least developers that You want to contribute to Postgres.) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
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: Windows Build System was: [HACKERS] Win32 port patches
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Windows Build System was: [HACKERS] Win32 port patches
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
