Re: Windows Build System was: Win32 port patches submitted - Mailing list pgsql-hackers
From | Kevin Brown |
---|---|
Subject | Re: Windows Build System was: Win32 port patches submitted |
Date | |
Msg-id | 20030125044651.GA12957@filer Whole thread Raw |
In response to | Re: Windows Build System was: Win32 port patches submitted ("Curtis Faith" <curtis@galtair.com>) |
List | pgsql-hackers |
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
pgsql-hackers by date: