Thread

Win32 port patches submitted

Jan Wieck <janwieck@yahoo.com> — 2003-01-20T22:06:28Z

Hi,

I just submitted the patches for the native Win32 port of v7.2.1 on the
patches mailing list.

If you are not subscribed to the patches list you can download them from

http://www.janwieck.net/win32_port


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

Re: Win32 port patches submitted

Peter Eisentraut <peter_e@gmx.net> — 2003-01-21T17:40:42Z

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

Re: Win32 port patches submitted

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-21T17:51:08Z

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

Re: Win32 port patches submitted

Jan Wieck <janwieck@yahoo.com> — 2003-01-21T18:03:09Z

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 #

Re: [mail] Re: Win32 port patches submitted

Al Sutton <al@alsutton.com> — 2003-01-21T18:06:26Z

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


> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

Re: [mail] Re: Win32 port patches submitted

Stephan Szabo <sszabo@megazone23.bigpanda.com> — 2003-01-21T18:45:50Z

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.

Re: [mail] Re: Win32 port patches submitted

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-21T20:17:53Z

"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

Re: [mail] Re: Win32 port patches submitted

Jan Wieck <janwieck@yahoo.com> — 2003-01-21T20:59:01Z

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 #

Re: [mail] Re: Win32 port patches submitted

Brian Bruns <camber@ais.org> — 2003-01-21T22:01:19Z

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:

> 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
> 
> 
> > 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
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
>

Re: [mail] Re: Win32 port patches submitted

Emmanuel Charpentier <charpent@bacbuc.dyndns.org> — 2003-01-21T22:36:50Z

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:
> 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:
> 
> 
>>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
>>
>>
>>
>>>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
>>>
>>>
>>>---------------------------(end of broadcast)---------------------------
>>>TIP 5: Have you checked our extensive FAQ?
>>>
>>>http://www.postgresql.org/users-lounge/docs/faq.html
>>>
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 5: Have you checked our extensive FAQ?
>>
>>http://www.postgresql.org/users-lounge/docs/faq.html
>>
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Re: [mail] Re: Win32 port patches submitted

Jan Wieck <janwieck@yahoo.com> — 2003-01-22T00:03:31Z

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 #

Re: [mail] Re: Win32 port patches submitted

Hans-Jürgen Schönig <postgres@cybertec.at> — 2003-01-22T06:53:31Z

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

Re: [mail] Re: Win32 port patches submitted

Emmanuel Charpentier <charpent@bacbuc.dyndns.org> — 2003-01-22T07:06:27Z

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

Re: [mail] Re: Win32 port patches submitted

Igor Georgiev <gory@alphasoft-bg.com> — 2003-01-22T11:26:50Z

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
> 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

Re: Windows Build System was: Win32 port patches submitted

Curtis Faith <curtis@galtair.com> — 2003-01-22T15:34:58Z

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.

Re: Windows Build System

Curtis Faith <curtis@galtcapital.com> — 2003-01-22T16:39:10Z

Curtis Faith wrote:
> > 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.

Hannu Krosing wrote:
> will probably change between releases

Even if the format changes, the environment always has a converter that
updates the project and workspace files to the new format. In other
words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.

The format is mostly a bunch of options specifications (which wouldn't
get touched) followed by a set of named groups of source files. Even if
the overall format changes, it will be much more likely to change in the
specifications rather than the way lists of source file formats are
specified.

A conversion script would only need to:

1) Read in the template file (containing all the options specifications
and Visual C++ speficic stuff, debug and release target options,
libraries to link in, etc.) This part might change with new versions of
the IDE and would be manually created by someone with Visual C++
experience.

2) Read in the postgreSQL group/directory map, or alternately just
mirror the groups with the directories.

3) Output the files from the PostgreSQL directories in the appropriate
grouping according to the project format into the appropriate space in
the template.

An excerpt of the format follows:

# Begin Group "Access"
# Begin Group "Common"
# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\common\heaptuple.c
# End Source File
# Begin Source File

SOURCE=.access\common\indextuple.c
# End Source File

... other files in access\common go here
# End Group

# Begin Group "Index"

# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\index\genam.c
# End Source File
# Begin Source File

SOURCE=.access\index\indexam.c
# End Source File

... other files in access\index go here
# End Group

# End Group

As you can see, this is a really easy format, and the folder/group
mapping with directories is pretty natural and probably the way to go.

Using the approach I outline, it should be possible to have the Unix
make system automatically run the BuildWindowsProjectFile tool whenever
any makefile changes so the Windows projects would stay up to date
without additional work for Unix developers.

Hannu Krosing also wrote:
> (also I dont think you can easily compile C source on a
> C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#. Why does this matter? I didn't propose targeting Visual
C#.NET.

- Curtis

Re: Windows Build System was: Win32 port patches

Hannu Krosing <hannu@tm.ee> — 2003-01-22T17:49:46Z

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>

Re: Windows Build System

Curtis Faith <curtis@galtair.com> — 2003-01-22T18:55:34Z

I (Curtis Faith) previously wrote:
> > 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.

Hannu Krosing replied:
> will probably change between releases

Even if the format changes, the environment always has a converter that
updates the project and workspace files to the new format. In other
words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.

The format is mostly a bunch of options specifications (which wouldn't
get touched) followed by a set of named groups of source files. Even if
the overall format changes, it will be much more likely to change in the
specifications rather than the way lists of source file formats are
specified.

A conversion tool, call it BuildWindowsProjectFile, would only need to:

1) Read in the template file (containing all the options specifications
and Visual C++ speficic stuff, debug and release target options,
libraries to link in, etc.) This part might change with new versions of
the IDE and would be manually created by someone with Visual C++
experience.

2) Read in the postgreSQL group/directory map, or alternately just
mirror the groups with the directories.

3) Output the files from the PostgreSQL directories in the appropriate
grouping according to the project format into the appropriate space in
the template.

An excerpt of the format follows:

# Begin Group "Access"
# Begin Group "Common"
# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\common\heaptuple.c
# End Source File
# Begin Source File

SOURCE=.access\common\indextuple.c
# End Source File

... other files in access\common go here
# End Group

# Begin Group "Index"

# PROP Default_Filter "cpp;c;cxx"
# Begin Source File

SOURCE=.\access\index\genam.c
# End Source File
# Begin Source File

SOURCE=.access\index\indexam.c
# End Source File

... other files in access\index go here
# End Group

# End Group

As you can see, this is a really simple format, and the direct
folder/group mapping to PostgreSQL directory is pretty natural and
probably the way to go.

Using the approach I outline, it should be possible to have the Unix
make system automatically run the BuildWindowsProjectFile tool whenever
any makefile changes so the Windows projects would stay up to date
without additional work for Unix developers.

Hannu Krosing also wrote:
> (also I dont think you can easily compile C source on a
> C# compiler) ;/

I don't think it makes much sense target a compiler that won't compile
the source, therefore, if what you say is true, we shouldn't bother with
targeting C#.

- Curtis

Re: Windows Build System was: Win32 port patches

bbaker@priefert.com <bbaker@priefert.com> — 2003-01-22T19:04:05Z
```
This is a multi-part message in MIME format.
```

Re: Windows Build System

Curtis Faith <curtis@galtair.com> — 2003-01-22T20:38:33Z

Hannu Krosing asked:
> Does anyone know how MySQL and interbase/firebird do it ?
> 

From the MySQL web site for version 4.0:

"The Windows binaries use the Cygwin library. Source code for the
version of Cygwin we have used is available on this page."

I think this offers a very big opportunity to differentiate. If we had
project support it would make PostgreSQL a more natural choice for
Windows developers.

Even in a shop that uses Unix servers with Windows front-ends, having a
database server that runs on your own machine makes it much easier to
debug, write code on airplanes, etc.

- Curtis

Re: Win32 port patches submitted

Peter Eisentraut <peter_e@gmx.net> — 2003-01-22T20:43:28Z

Jan Wieck writes:

> 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).

I have prepared a little patch that makes room for a native Windows build
in our existing build framework.  The Cygwin port would be renamed to
"cygwin" and the new port takes over the "win" name.  I have prepared the
port specific template and makefile and extracted the dynaloader from your
patch, so that you can at least run configure under Cygwin or MinGW
successfully.

Then I suggest we merge in the obvious parts of your patch, especially the
renaming of various token constants, the shmem implementation, some
library function reimplementations.  In some cases I would like a bit more
abstraction so that we don't have so many #ifdef's.  (For example, we
could have a IsAbsolutePath() that works magically for all platforms.)

Then there are the hairy pieces.  You add a bunch of command-line options
that interact in puzzling way to communicate information about the fake
fork.  I think some of these are redundant, but it's hard to tell.

The reimplementation of various shell scripts in C is something that would
be a good idea on Unix as well for a number of reasons.  Unfortunately,
the ones you wrote have no chance of compiling under Unix, so we'll have
to do it again.  But that can happen in parallel to the other stuff.

Two quick questions:  Why PG_WIN32 and not just WIN32?  Can the ConsoleApp
thing be written in C so we don't have to get an extra C++ compiler for
one file (for those who don't want to use the Microsoft toolchain)?

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Windows Build System was: Win32 port patches

bbaker@priefert.com <bbaker@priefert.com> — 2003-01-22T20:47:10Z

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

Re: Windows Build System

Adrian Maier <am@fx.ro> — 2003-01-23T08:04:42Z

On Wed, Jan 22, 2003 at 02:55:34PM -0400, Curtis Faith wrote:
> 
> Hannu Krosing also wrote:
> > (also I dont think you can easily compile C source on a
> > C# compiler) ;/
> 
> I don't think it makes much sense target a compiler that won't compile
> the source, therefore, if what you say is true, we shouldn't bother with
> targeting C#.

I don't think that compiling on a C# compiler is possible at all.
C# is too different from C. In fact, the C# language is much more similar 
to Java than C/C++ ( there are no pointers, for example ).

-- 
Adrian Maier
(am@fx.ro, 40 723.002.097)

Re: Windows Build System was: Win32 port patches

Darko Prenosil <darko.prenosil@finteh.hr> — 2003-01-23T10:50:13Z

On Wednesday 22 January 2003 20:47, bbaker@priefert.com 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.)

Re: Windows Build System was: Win32 port patches submitted

Kevin Brown <kevin@sysexperts.com> — 2003-01-25T04:46:51Z

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

Re: Win32 port patches submitted

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-26T03:07:41Z

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.  I don't mind Cygwin if we don't have licensing problems with
distributing a Win32 binary that used Cygwin to build.  I do have a
problem with MKS toolkit, which is a commerical purchase.  I would like
to avoid reliance on that, though Jan said he needed their bash.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Win32 port patches submitted

Hannu Krosing <hannu@tm.ee> — 2003-01-26T09:35:24Z

Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:
> 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.  I don't mind Cygwin if we don't have licensing problems with
> distributing a Win32 binary that used Cygwin to build.  I do have a
> problem with MKS toolkit, which is a commerical purchase.  I would like
> to avoid reliance on that, though Jan said he needed their bash.

IIRC mingw tools had win-native (cygwin-less) bash at

http://sourceforge.net/projects/mingw/

-- 
Hannu Krosing <hannu@tm.ee>

Re: Win32 port patches submitted

Justin Clift <justin@postgresql.org> — 2003-01-26T13:30:34Z

Hannu Krosing wrote:
> Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:
> 
>>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.  I don't mind Cygwin if we don't have licensing problems with
>>distributing a Win32 binary that used Cygwin to build.  I do have a
>>problem with MKS toolkit, which is a commerical purchase.  I would like
>>to avoid reliance on that, though Jan said he needed their bash.
> 
> 
> IIRC mingw tools had win-native (cygwin-less) bash at
> 
> http://sourceforge.net/projects/mingw/

Have been watching this ongoing conversation and am in two frames of 
mind about:

  + There are a lot of people on Win32 that are using MS Visual C or 
Visual Studio

  + There are a few fairly well established Win32 programming IDE's that 
are compatible with cygwin/mingw32

The advantages to having the Win32 port be natively compatible with 
Visual Studio is that it already is (no toolset-porting work needed 
there), but the disadvantage is that not just any Win32 
user-with-an-interest can download it any try it out.  So... that kind 
of excludes it somewhat (Universities/colleges might have a problem too).

The advantages of having the Win32 port be natively compatible with 
gcc/cygwin/something is that once it's converted to that toolchain, it 
might be a lot less maintenance on us, as that's the toolset we use for 
the Unix builds.

As a thought, the open source Dev-C++ IDE (Win32 and Linux) works with 
gcc/cygwin/mingw32 and is pretty popular.  Just checked it's homepage on 
SourceForge (http://sourceforge.net/projects/dev-cpp/) and it's download 
figures are pretty large.  Since March 2002 (less than 1 year ago), it's 
been downloaded about 120,000,000 times.  Wow.  120 Million downloads in 
  less than 1 year.  That's a pretty popular IDE (16th most popular 
project on SourceForge)

Anyway, as a thought, my vote would be to make the Win32 port work in 
with our toolchain or very similar (cygwin/mingw32/etc) if possible, so 
we don't have to rely on people having Visual C.  In developing 
countries too, it's going to be much easier for people to get a hold of 
things like Dev-C++ into the future as well.

Hope this provides a useful set of thoughts.

:-)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Re: Win32 port patches submitted

Justin Clift <justin@postgresql.org> — 2003-01-26T13:50:41Z

Justin Clift wrote:
<snip>
> Since March 2002 (less than 1 year ago), it's 
> been downloaded about 120,000,000 times.  Wow.  120 Million downloads in 
>  less than 1 year.  That's a pretty popular IDE (16th most popular 
> project on SourceForge)


Arrrgh.  Thought that sounded a bit too high.

Wrong column, it's actually only about 2 million times, not 120 million.

Should probably get more sleep.  ;-)

Sorry about that guys.

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Re: Windows Build System

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-27T00:57:43Z

Are there no already-written converters from Makefile to VC project
files?

---------------------------------------------------------------------------

Curtis Faith wrote:
> I (Curtis Faith) previously wrote:
> > > 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.
> 
> Hannu Krosing replied:
> > will probably change between releases
> 
> Even if the format changes, the environment always has a converter that
> updates the project and workspace files to the new format. In other
> words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.
> 
> The format is mostly a bunch of options specifications (which wouldn't
> get touched) followed by a set of named groups of source files. Even if
> the overall format changes, it will be much more likely to change in the
> specifications rather than the way lists of source file formats are
> specified.
> 
> A conversion tool, call it BuildWindowsProjectFile, would only need to:
> 
> 1) Read in the template file (containing all the options specifications
> and Visual C++ speficic stuff, debug and release target options,
> libraries to link in, etc.) This part might change with new versions of
> the IDE and would be manually created by someone with Visual C++
> experience.
> 
> 2) Read in the postgreSQL group/directory map, or alternately just
> mirror the groups with the directories.
> 
> 3) Output the files from the PostgreSQL directories in the appropriate
> grouping according to the project format into the appropriate space in
> the template.
> 
> An excerpt of the format follows:
> 
> # Begin Group "Access"
> # Begin Group "Common"
> # PROP Default_Filter "cpp;c;cxx"
> # Begin Source File
> 
> SOURCE=.\access\common\heaptuple.c
> # End Source File
> # Begin Source File
> 
> SOURCE=.access\common\indextuple.c
> # End Source File
> 
> ... other files in access\common go here
> # End Group
> 
> # Begin Group "Index"
> 
> # PROP Default_Filter "cpp;c;cxx"
> # Begin Source File
> 
> SOURCE=.\access\index\genam.c
> # End Source File
> # Begin Source File
> 
> SOURCE=.access\index\indexam.c
> # End Source File
> 
> ... other files in access\index go here
> # End Group
> 
> # End Group
> 
> 
> As you can see, this is a really simple format, and the direct
> folder/group mapping to PostgreSQL directory is pretty natural and
> probably the way to go.
> 
> Using the approach I outline, it should be possible to have the Unix
> make system automatically run the BuildWindowsProjectFile tool whenever
> any makefile changes so the Windows projects would stay up to date
> without additional work for Unix developers.
> 
> Hannu Krosing also wrote:
> > (also I dont think you can easily compile C source on a
> > C# compiler) ;/
> 
> I don't think it makes much sense target a compiler that won't compile
> the source, therefore, if what you say is true, we shouldn't bother with
> targeting C#.
> 
> - Curtis
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: [mail] Re: Windows Build System

Al Sutton <al@alsutton.com> — 2003-01-27T07:59:18Z

Theres a script at http://ptolemy.eecs.berkeley.edu/other/makevcgen which
may work, I've not tried it, but someone may want to give it a spin.

Combining it with the software at http://unxutils.sourceforge.net could give
us a MS build environment which only relies on installation support programs
rather than relying on the installation and use of the whole Cygwin
environment for the build process.

Al.

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Curtis Faith" <curtis@galtair.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Monday, January 27, 2003 12:57 AM
Subject: [mail] Re: [HACKERS] Windows Build System


>
> Are there no already-written converters from Makefile to VC project
> files?
>
> --------------------------------------------------------------------------
-
>
> Curtis Faith wrote:
> > I (Curtis Faith) previously wrote:
> > > > 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.
> >
> > Hannu Krosing replied:
> > > will probably change between releases
> >
> > Even if the format changes, the environment always has a converter that
> > updates the project and workspace files to the new format. In other
> > words, Visual C++ 6.0 reads 5.0 projects, 7.0 reads 6.0, etc.
> >
> > The format is mostly a bunch of options specifications (which wouldn't
> > get touched) followed by a set of named groups of source files. Even if
> > the overall format changes, it will be much more likely to change in the
> > specifications rather than the way lists of source file formats are
> > specified.
> >
> > A conversion tool, call it BuildWindowsProjectFile, would only need to:
> >
> > 1) Read in the template file (containing all the options specifications
> > and Visual C++ speficic stuff, debug and release target options,
> > libraries to link in, etc.) This part might change with new versions of
> > the IDE and would be manually created by someone with Visual C++
> > experience.
> >
> > 2) Read in the postgreSQL group/directory map, or alternately just
> > mirror the groups with the directories.
> >
> > 3) Output the files from the PostgreSQL directories in the appropriate
> > grouping according to the project format into the appropriate space in
> > the template.
> >
> > An excerpt of the format follows:
> >
> > # Begin Group "Access"
> > # Begin Group "Common"
> > # PROP Default_Filter "cpp;c;cxx"
> > # Begin Source File
> >
> > SOURCE=.\access\common\heaptuple.c
> > # End Source File
> > # Begin Source File
> >
> > SOURCE=.access\common\indextuple.c
> > # End Source File
> >
> > ... other files in access\common go here
> > # End Group
> >
> > # Begin Group "Index"
> >
> > # PROP Default_Filter "cpp;c;cxx"
> > # Begin Source File
> >
> > SOURCE=.\access\index\genam.c
> > # End Source File
> > # Begin Source File
> >
> > SOURCE=.access\index\indexam.c
> > # End Source File
> >
> > ... other files in access\index go here
> > # End Group
> >
> > # End Group
> >
> >
> > As you can see, this is a really simple format, and the direct
> > folder/group mapping to PostgreSQL directory is pretty natural and
> > probably the way to go.
> >
> > Using the approach I outline, it should be possible to have the Unix
> > make system automatically run the BuildWindowsProjectFile tool whenever
> > any makefile changes so the Windows projects would stay up to date
> > without additional work for Unix developers.
> >
> > Hannu Krosing also wrote:
> > > (also I dont think you can easily compile C source on a
> > > C# compiler) ;/
> >
> > I don't think it makes much sense target a compiler that won't compile
> > the source, therefore, if what you say is true, we shouldn't bother with
> > targeting C#.
> >
> > - Curtis
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania
19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>

Re: [mail] Re: Windows Build System

Curtis Faith <curtis@galtcapital.com> — 2003-01-27T17:02:32Z

> ----- Original Message -----
Bruce Momjian replied
> > Are there no already-written converters from Makefile to VC project 
> > files?

The only ones I've seen convert from Unix make files to Windows NMAKE
make files. This does not really do everything you want for several
reasons:

1) Building with make files doesnt take advantage of the IDE for code
organization, navigation and is not the kind of support that would be
included for a "well supported" Windows product.

2) There is no automatic way to convert compiler options from gcc to
Visual C

3) There is no way to convert the concept of different build targets
(debug, release, etc.) in the way that the IDE looks at it. This is
analogous but different from the way a make file handles different
targets.

4) There was some discussion on the list that some features of Visual
C++ were required for the port itself, something about directory
replacement for include files. It is likely that this requires a special
setup for the Visual C++ project which would not be easy to handle with
just a NMAKE combatible make file.

Al Sutton replied:
> Theres a script at 
> http://ptolemy.eecs.berkeley.edu/other/makevcgen which may 
> work, I've not tried it, but someone may want to give it a spin.

The script he describes here is one of the make file converters I
describe above.

I volunteer to write a tool in generic C to do the conversion if the
approach I outlined is deemed a good solution by those that decide such
things.

The real question is what is the motivator for a native Windows port. If
the answer is to remove CygWin dependency, that begs the further
question of why is removing CygWin dependency a good idea? 

One of the reasons has to be that any obstacles that stand in the way of
getting an implementation compiled and installed will make it less
likely that developers will use it.I believe that a native Windows
version that had strong Visual C++ support will win many converts from
MySQL because it will make it much easier for someone who is looking for
an open source database to try compiling PostgreSQL. Most people looking
at open source solutions will want to at least poke around in the source
and build from that source.

If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they will be more likely to use it for Windows projects
than MySQL which requires the CygWin tools (this means "really a Unix
product" to Windows developers).

- Curtis

Re: Win32 port patches submitted

Peter Eisentraut <peter_e@gmx.net> — 2003-01-27T21:09:45Z

Bruce Momjian writes:

> I do have a problem with MKS toolkit, which is a commerical purchase.
> I would like to avoid reliance on that, though Jan said he needed their
> bash.

I don't believe that quite yet.  Jan said the regression test script
crashes Cygwin's bash, but how come it has never crashed anyone else's
Cygwin bash?

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Win32 port patches submitted

Peter Eisentraut <peter_e@gmx.net> — 2003-01-27T21:10:02Z

Justin Clift writes:

> The advantages to having the Win32 port be natively compatible with
> Visual Studio is that it already is (no toolset-porting work needed
> there),

You're missing a couple of points here.  First, the MS Visual whatever
compiler can also be used with a makefile-driven build system.  Second,
the port as it stands isn't really compatible with anything except Jan's
build instructions.  There's a lot of work to be done before we get
anything that builds out of the box in the 7.4 branch, and it's going to
be a lot easier if we do it using the build system we already have and
know.

-- 
Peter Eisentraut   peter_e@gmx.net

Re: Win32 port patches submitted

Justin Clift <justin@postgresql.org> — 2003-01-28T03:57:36Z

Peter Eisentraut wrote:
> Justin Clift writes:
> 
>>The advantages to having the Win32 port be natively compatible with
>>Visual Studio is that it already is (no toolset-porting work needed
>>there),
> 
> You're missing a couple of points here.  First, the MS Visual whatever
> compiler can also be used with a makefile-driven build system.  Second,
> the port as it stands isn't really compatible with anything except Jan's
> build instructions.  There's a lot of work to be done before we get
> anything that builds out of the box in the 7.4 branch, and it's going to
> be a lot easier if we do it using the build system we already have and
> know.

Thanks Peter.  Really didn't know that MS Visual <things> could work 
with makefile driven build systems, nor that the PeerDirect build 
process was so... unique.  :)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Re: Windows Build System was: Win32 port patches

Alan Gutierrez <ajglist@izzy.net> — 2003-01-28T18:20:21Z

On Wednesday 22 January 2003 11:49, Hannu Krosing wrote:
> 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 ?

Xerces and Xalan from Apache both include VC6 projects. The projects are
kept in their own directory apart from source code. You might want to
download the Xerces and Xalan source and look at how they structured
their envrionment.

I *does* make it easier for Windows developers to work with VC6 projects.

Alan Gutierrez - ajglist@izzy.net
http://khtml-win32.sourceforge.net/ - KHTML on Windows

Re: [mail] Re: Windows Build System

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-29T08:37:11Z

"Curtis Faith" <curtis@galtcapital.com> writes:
> If a developer can simply download the source, click on the Visual C++
> project in the win32 directory and then build PostgreSQL, and they can
> see that Windows is not the "poor stepchild" because the VC project is
> well laid out, they will be more likely to use it for Windows projects
> than MySQL which requires the CygWin tools (this means "really a Unix
> product" to Windows developers).

<flame on>
In all honesty, I do not *want* Windows people to think that they're not
running on the "poor stepchild" platform.    If we go down that path,
they'll start trying to run production databases on Windows, and then
we'll get blamed for the instability of the platform, not to mention
the likelihood that it ignores Unix semantics for fsync() and suchlike
critical primitives.

I have no objection to there being a Windows port that people can use
to do SQL-client development on their laptops.  But let us please not
confuse this with an industrial-strength solution; nor give any level
of support that might lead others to make such confusion.

The MySQL guys made the right choice here: they don't want to buy into
making Windows a grade-A platform, either.
<flame off>

			regards, tom lane

Re: [mail] Re: Windows Build System

Katie Ward <kward@peerdirect.com> — 2003-01-29T16:18:17Z


> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Wednesday, January 29, 2003 3:37 AM
> To: Curtis Faith
> Cc: 'Al Sutton'; 'Bruce Momjian'; pgsql-hackers@postgresql.org
> Subject: Re: [mail] Re: [HACKERS] Windows Build System
>
>
> "Curtis Faith" <curtis@galtcapital.com> writes:
> > If a developer can simply download the source, click on the Visual C++
> > project in the win32 directory and then build PostgreSQL, and they can
> > see that Windows is not the "poor stepchild" because the VC project is
> > well laid out, they will be more likely to use it for Windows projects
> > than MySQL which requires the CygWin tools (this means "really a Unix
> > product" to Windows developers).
>
> <flame on>
> In all honesty, I do not *want* Windows people to think that they're not
> running on the "poor stepchild" platform.    If we go down that path,
> they'll start trying to run production databases on Windows, and then
> we'll get blamed for the instability of the platform, not to mention
> the likelihood that it ignores Unix semantics for fsync() and suchlike
> critical primitives.
>
> I have no objection to there being a Windows port that people can use
> to do SQL-client development on their laptops.  But let us please not
> confuse this with an industrial-strength solution; nor give any level
> of support that might lead others to make such confusion.
>
> The MySQL guys made the right choice here: they don't want to buy into
> making Windows a grade-A platform, either.
> <flame off>
>
> 			regards, tom lane

Wow.  I've been listening to the pros and cons for a while, and they've been
really interesting.  However, to assume without ever using the native
Windows port that it is automatically a "poor stepchild" is unbelievable.

I believe that the port, as submitted, can be used as an industrial-strength
solution.  I challenge you all to prove me wrong, but until you do, please
lay off the assumptions.

Regards,
Katie Ward
Principle Developer
PeerDirect Corporation

Re: [mail] Re: Windows Build System

Vince Vielhaber <vev@michvhf.com> — 2003-01-29T16:27:26Z

On Wed, 29 Jan 2003, Katie Ward wrote:

> > <flame on>
> > In all honesty, I do not *want* Windows people to think that they're not
> > running on the "poor stepchild" platform.    If we go down that path,
> > they'll start trying to run production databases on Windows, and then
> > we'll get blamed for the instability of the platform, not to mention
> > the likelihood that it ignores Unix semantics for fsync() and suchlike
> > critical primitives.
> >
> > I have no objection to there being a Windows port that people can use
> > to do SQL-client development on their laptops.  But let us please not
> > confuse this with an industrial-strength solution; nor give any level
> > of support that might lead others to make such confusion.
> >
> > The MySQL guys made the right choice here: they don't want to buy into
> > making Windows a grade-A platform, either.
> > <flame off>
> >
> > 			regards, tom lane
>
> Wow.  I've been listening to the pros and cons for a while, and they've been
> really interesting.  However, to assume without ever using the native
> Windows port that it is automatically a "poor stepchild" is unbelievable.
>
> I believe that the port, as submitted, can be used as an industrial-strength
> solution.  I challenge you all to prove me wrong, but until you do, please
> lay off the assumptions.

The only assumption I see being made here is this:

"I believe that the port, as submitted, can be used as an
industrial-strength solution."

I see no evidence to support this claim.  If you have this evidence,
feel free to share it with the rest of us.

Vince.
-- 
 Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
   http://www.meanstreamradio.com       http://www.unknown-artists.com
         Internet radio: It's not file sharing, it's just radio.

Re: Win32 port patches submitted

Jan Wieck <janwieck@yahoo.com> — 2003-01-29T19:47:01Z

Peter Eisentraut wrote:
> 
> Justin Clift writes:
> 
> > The advantages to having the Win32 port be natively compatible with
> > Visual Studio is that it already is (no toolset-porting work needed
> > there),
> 
> You're missing a couple of points here.  First, the MS Visual whatever
> compiler can also be used with a makefile-driven build system.  Second,
> the port as it stands isn't really compatible with anything except Jan's
> build instructions.  There's a lot of work to be done before we get
> anything that builds out of the box in the 7.4 branch, and it's going to
> be a lot easier if we do it using the build system we already have and
> know.

Absolutely right, I know that the build environment is more a mess than
an environment. All I said is that we have a stable, working, native
Win32 PostgreSQL 7.2.1 ... 

And I don't care if we use MingW, Borland, Cygwin or a big blend of it
all, as long as the final result can be shipped binary under the BSD
license. 


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

Re: [mail] Re: Windows Build System

Kevin Brown <kevin@sysexperts.com> — 2003-01-30T05:29:04Z

Tom Lane wrote:
> "Curtis Faith" <curtis@galtcapital.com> writes:
> > If a developer can simply download the source, click on the Visual C++
> > project in the win32 directory and then build PostgreSQL, and they can
> > see that Windows is not the "poor stepchild" because the VC project is
> > well laid out, they will be more likely to use it for Windows projects
> > than MySQL which requires the CygWin tools (this means "really a Unix
> > product" to Windows developers).
> 
> <flame on>
> In all honesty, I do not *want* Windows people to think that they're not
> running on the "poor stepchild" platform.    If we go down that path,
> they'll start trying to run production databases on Windows, and then
> we'll get blamed for the instability of the platform, not to mention
> the likelihood that it ignores Unix semantics for fsync() and suchlike
> critical primitives.

Unless this concern is the result of experience (with, say, some
versions of Linux or whatnot), then I'd be more inclined to take a
"try it and see" attitude.

I do think it's quite appropriate to make the world aware that
PostgreSQL under Windows is not likely to be as dependable as
PostgreSQL under other Unix platforms, if only because the underlying
platform isn't as stable.

The fsync() issue and others like it can hopefully be settled through
testing.  Frankly, I will be surprised if it doesn't work (but not
*too* surprised :-).

> I have no objection to there being a Windows port that people can use
> to do SQL-client development on their laptops.  But let us please not
> confuse this with an industrial-strength solution; nor give any level
> of support that might lead others to make such confusion.

I don't believe the level of support this group provides has anything
to do with whether or not others will regard PostgreSQL on Windows to
be an industrial strength solution.  Only their experience will
determine that.  Because PostgreSQL doesn't have a huge marketing arm,
its reputation is built upon word of mouth, which is something that
only comes from experience.

You're assuming that if PostgreSQL is made available under Windows
such that it can be run as a service, people who deploy it will
immediately assume that it's an industrial strength solution.  I think
that assumption is faulty, because in reality people out there in the
real world are reluctant to deploy PostgreSQL under *Unix* as an
industrial strength solution despite its high reliability.  Otherwise
PostgreSQL would be a LOT more popular than it is.

It takes time and experience for people to be convinced that something
is industrial-strength, and the Windows port of PostgreSQL is no
exception.

Perhaps your real concern here is that a port of PostgreSQL to Windows
might negatively impact the overall reputation of PostgreSQL due to
the fragility of Windows.  But I don't think that's really much of a
concern: I don't believe the overall reputation of Oracle suffered due
to its Windows port, for instance.  I think most people who really
care about such things are aware that Windows as a platform isn't as
reliable as Unix and take that into account when judging the
reliability of a deployed solution.

For judging the reliability PostgreSQL under Windows, what would
matter would be how it stacks up against other database engines
running under Windows.  In other words, take Windows out of the
comparison equation.  If PostgreSQL under Windows is at least as fast,
solid, etc., as MS-SQL, DB/2, or Oracle under Windows, then people
will rightly think of PostgreSQL as an industrial-strength solution
and the reputation of PostgreSQL will be secure despite the failings
of the platform relative to Unix.

Bottom line: put tons of disclaimers about the likely reliability of
the Windows port in the documentation if you'd like, but don't let
these concerns prevent any action with respect to doing a proper
Windows port.

-- 
Kevin Brown					      kevin@sysexperts.com

Re: [mail] Re: Windows Build System

Mark Woodward <pgsql@mohawksoft.com> — 2003-01-31T20:46:20Z

Tom Lane wrote:

>"Curtis Faith" <curtis@galtcapital.com> writes:
>  
>
>>If a developer can simply download the source, click on the Visual C++
>>project in the win32 directory and then build PostgreSQL, and they can
>>see that Windows is not the "poor stepchild" because the VC project is
>>well laid out, they will be more likely to use it for Windows projects
>>than MySQL which requires the CygWin tools (this means "really a Unix
>>product" to Windows developers).
>>    
>>
>
><flame on>
>In all honesty, I do not *want* Windows people to think that they're not
>running on the "poor stepchild" platform.    If we go down that path,
>they'll start trying to run production databases on Windows, and then
>we'll get blamed for the instability of the platform, not to mention
>the likelihood that it ignores Unix semantics for fsync() and suchlike
>critical primitives.
>
>I have no objection to there being a Windows port that people can use
>to do SQL-client development on their laptops.  But let us please not
>confuse this with an industrial-strength solution; nor give any level
>of support that might lead others to make such confusion.
>
>The MySQL guys made the right choice here: they don't want to buy into
>making Windows a grade-A platform, either.
><flame off>
>
OK, I have to weigh in here.

I have been a Windows application and kernel driver developer since 
version 1.0. I have also worked on UNIX since the original Sun machines. 
 Yes, the DOS version of Windows, i.e win95/98/ME is pure unmitigated 
crap. No doubt. The NT version of Windows, NT/2K/XP has a very well 
designed kernel. It is more or less based on OpenVMS. To say it is a 
"poor stepchild" shows a lack of imagination on your part.

The NT lineage of Windows is usable as a production server. I think 
PostgreSQL using the most pedestrian Win32 API entry points will perform 
just fine. The core disk I/O subsystem and NTFS are very stable. The 
scheduler is not great, but is usable. The VM system is probably better 
than most UNIX environments, including FreeBSD and Linux. The always 
interruptable always reentrant device driver design could crank out some 
serious performance on a busy server.

That being said, the kernel level GUI of Windows is a dangerous risk. 
Many of the changes made since the original NT (3.x) do reduce stability 
in a desktop environment. However, a server environment, such as PG, 
which does not perform any graphic interactions should be stable enough. 
If rebooted once a every month or two, the system should never 
experience data loss and windows admins are used to doing periodic reboots.

One last, IMHO very important point, A LOT OF PEOPLE USE WINDOWS!

Every effort should be made to support it. Yea, we all have our favorite 
environments. I choose Linux, others choose a *BSD, some use HPUX, 
Solaris or whatever. The point is a lot people choose Windows. It is 
possible to make a stable environment on this platform. Would I choose 
it? No, but some people do. Don't you think it makes sense to provide a 
good solution on Windows, and if they run into the inherent limitations 
of that platform be able to say, "Windows has some serious design flaws, 
but you can upgrade to Solaris or HPUX if you need" and getting the 
user,  instead of saying, "Windows sucks, use a real platform" and 
losing them?

I think it is a AWESOME story to say, "Build your app using PG. Start 
with Windows, if you like, we don't care, if you grow beyond the 
capabilities of Windows, just upgrade your server, no need to change 
anything else."

Just my $0.02

Mark