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
