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

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

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:

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:

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 #

-----Original Message-----
From: Jan Wieck [mailto:JanWieck@Yahoo.com]
Sent: Tuesday, January 21, 2003 4:04 PM
To: Emmanuel Charpentier
Cc: pgsql-hackers@postgresql.org
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 ...

GDB works fine. Some of the other tools don't work right (e.g. sed is
broken).

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&gt;, cluster.postgresql.at
<http://cluster.postgresql.at&gt;, www.cybertec.at
<http://www.cybertec.at&gt;, kernel.cybertec.at <http://kernel.cybertec.at&gt;

-----Original Message-----
From: Hans-Jürgen Schönig [mailto:postgres@cybertec.at]
Sent: Tuesday, January 21, 2003 10:54 PM
To: Brian Bruns; pgsql-hackers@postgresql.org
Subject: Re: [mail] Re: [HACKERS] Win32 port patches submitted

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.

Maybe because most of the machines in the world (by a titanic landslide) are Windoze boxes.

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.

Sounds like a Windows port to me. How is this "Windows build" going to be created without a "Windows port"?

I don't
expect many
people to do it. Usually Open Source guys run *NIX

Taken a poll lately?

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.

It was simple to build. And if you don't want to build it, they have binary distributions. I have SAP/DB running on this machine (along with SQL*Server, PostgreSQL, DB/2, Oracle, Firebird and a few others) SAP DB is or can be used for SAP (basically, it's a port of Adabas). That makes it kind of important, for obvious reasons.

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

Dann Corbit wrote:

[ ... ]

GDB works fine. Some of the other tools don't work right (e.g. sed is
broken).

Recent fixes exist, but I didn't check all of them. WorksForMe(TM), but my
projects are *much* simpler ...

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

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 Wednesday 22 January 2003 02:01, Dann Corbit wrote:

Maybe because most of the machines in the world (by a titanic landslide)
are Windoze boxes.

On the desktop, yes. On the server, no. PostgreSQL is nore intended for a
server, no? I can see the utility in having a development installation on a
Win32 box, though.

people to do it. Usually Open Source guys run *NIX

Taken a poll lately?

If Microsoft has its way there won't be any Open Source on Windows. Well,
PostgreSQL might squeak by due to the BSD license, but other licenses aren't
so fortunate, and GPL is anathema to Microsoft.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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>