Re: Windows Build System was: Win32 port patches submitted - Mailing list pgsql-hackers

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.