Re: [HACKERS] Win32 port patches submitted

[Dann Corbit]

> -Original Message-
> From: Jan Wieck [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, January 29, 2003 11:47 AM
> To: Peter Eisentraut
> Cc: Justin Clift; Hannu Krosing; Bruce Momjian; Tom Lane; 
> Postgres development
> Subject: Re: [HACKERS] Win32 port patches submitted
> 
> 
> 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. 

It would be very nice if we could drive the whole thing under Mingw.  It
has an environment that the current developers will be familiar with
(bash, ksh, GCC, etc.) and probably some scripts could perform all the
manual operations.

Is there a place I can download the current patched tree?  I might look
at automating the process to some degree.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Win32 port patches submitted

[Jan Wieck]

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.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Win32 port patches submitted

[Justin Clift]

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


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Win32 port patches submitted

[Peter Eisentraut]

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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Win32 port patches submitted

[Peter Eisentraut]

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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Win32 port patches submitted

[Justin Clift]

Justin Clift wrote:


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


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Win32 port patches submitted

[Justin Clift]

Hannu Krosing wrote:

Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:


Tom Lane wrote:


Peter Eisentraut <[EMAIL PROTECTED]> 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


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Win32 port patches submitted

[Hannu Krosing]

Bruce Momjian kirjutas P, 26.01.2003 kell 05:07:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Win32 port patches submitted

[Bruce Momjian]

Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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
  [EMAIL PROTECTED]   |  (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: Windows Build System was: [HACKERS] Win32 port patches submitted

[Kevin Brown]

Curtis Faith wrote:
> tom lane writes:
> > You think we should drive away our existing unix developers 
> > in the mere hope of attracting windows developers?  Sorry, it 
> > isn't going to happen.
> 
> Tom brings up a good point, that changes to support Windows should not
> add to the tasks of those who are doing the bulk of the work on Unixen.
> 
> I don't think, however, that this necessarily means that having Windows
> developers use Cygwin is the right solution. We need to come up with a
> way to support Windows Visual C++ projects without adding work to the
> other developers. 

[...]

> IMHO, having a native port without native (read Visual C++) project
> support is a a huge missed opportunity.

Perhaps.  On the other hand, it may be much more work than it's worth.
See below.

> The Visual C++ environment does not require dependency specification, it
> builds dependency trees by keeping track of the #include files used
> during preprocessing.
> 
> Because of this, it should be possible to:
> 
> A) Write a script/tool that reads the input files from Unix makefiles to
> build a list of the files in PostgreSQL and place them in appropriate
> projects.
> 
> or alternately:
> 
> B) A script/tool that recurses the directories and does the same sort of
> thing. There could be some sort of mapping between directories and
> projects in Visual C++.


This may be necessary, but I seriously doubt it's anywhere close to
sufficient.  Right now, the Unix build relies on GNU autoconf to
generate the Makefiles and many other files (even include files).  And
it doesn't just look for system-specific features and whatnot: it's
the means by which features are selected at build time (such as SSL
support, Kerberos support, which langauges to build runtime support
for, etc.).  To use it requires a Unix shell and a bunch of command
line tools (e.g., sed).  That's why Cygwin is required right now.

Somehow *all* of that has to either be replaced, or someone has to
decide which features will be built by all developers, or someone has
to do all the legwork of making the Windows source tree roughly as
configurable as the Unix one is.  Doesn't sound like a terribly small
task to me, though it might not be too bad for someone who has a lot
of experience on both platforms.  Since I don't have any real
experience doing development under Windows, I'm not one to really say.
But I thought you should at least know what you're up against.


I do agree that being able to build and debug PostgreSQL using
whichever tools are most commonly used amongst Windows developers
would be desirable, perhaps very much so...


-- 
Kevin Brown   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Win32 port patches submitted

[Peter Eisentraut]

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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Lamar Owen]

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


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: Windows Build System was: [HACKERS] Win32 port patches submitted

[Curtis Faith]

tom lane writes:
> You think we should drive away our existing unix developers 
> in the mere hope of attracting windows developers?  Sorry, it 
> isn't going to happen.

Tom brings up a good point, that changes to support Windows should not
add to the tasks of those who are doing the bulk of the work on Unixen.

I don't think, however, that this necessarily means that having Windows
developers use Cygwin is the right solution. We need to come up with a
way to support Windows Visual C++ projects without adding work to the
other developers. 

I believe this is possible and have outlined some ways at the end, but
first some rationale:

One of the biggest benefits to Open Source projects is the ability to
get in there and debug/fix problems using the source. PostgreSQL will
lose out to lesser DBs if there is no easy way to build and DEBUG the
source on Windows. This is true whether one admits that Windows sucks or
not.

A developer faced with the decision of choosing:

A) a system that has a native Windows Visual C++ project that runs and
compiles the release with no work.

B) a system that requires learning a new way of building, new tools, new
who knows what else.

will always choose A unless there is a very compelling reason to choose
B. There are plenty of reasons a clever (or even not so clever) Windows
developer can use to justify using MySQL or another open source DB
instead of PostgreSQL. It is a bit harder for the neophyte to find and
believe the compelling reasons to use PostgreSQL. We need to make it
easier to choose PostgreSQL not harder.

Think about it from this perspective. How many of you would even think
about working on a project if it required that you stop using your
favorite toolset, gmake? EMACS? grep? shell scripts? etc.?

Professional developers spend years honing their skills. Learning the
proper use of the tools involved is a very big part of the process.

IMHO, having a native port without native (read Visual C++) project
support is a a huge missed opportunity.

Further, lack of Windows project files implies that PostgreSQL just a
Unix port and that the Windows support is immature, whether the code is
well supported or not.

POSSIBLE SOLUTIONS:

The Visual C++ Workspaces and Projects files are actually text files
that have a defined format. I don't think the format is published but it
looks pretty easy to figure out.

The Visual C++ environment does not require dependency specification, it
builds dependency trees by keeping track of the #include files used
during preprocessing.

Because of this, it should be possible to:

A) Write a script/tool that reads the input files from Unix makefiles to
build a list of the files in PostgreSQL and place them in appropriate
projects.

or alternately:

B) A script/tool that recurses the directories and does the same sort of
thing. There could be some sort of mapping between directories and
projects in Visual C++.

In short, for most organizations being able to easily build using the
source is a prerequisite for USING an open source database, not just for
being part of the DEVELOPMENT effort.

-Curtis

P.S. I speak from personal experience, I would have been able to help
out a lot more if I didn't have to spend 90% of my time working with
PostgreSQL learning Unix (or relearning) and gnu tool issues. I don't
personally mind so much because I wanted to learn it better anyway, but
it has definitely limited my ability to help, so far. This is especially
true since I don't have the opportunity to immerse myself in
Unix/PostgreSQL for days at a time and suffer from significant switching
costs.





---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Dann Corbit]

> -Original Message-
> From: Hans-Jürgen Schönig [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, January 21, 2003 10:54 PM
> To: Brian Bruns; [EMAIL PROTECTED]
> 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. 
> >  
> >
> 
> 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.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Hans-Jürgen Schönig]

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. 
 


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



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Brian Bruns]

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. 

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" <[EMAIL PROTECTED]>
> To: "Jan Wieck" <[EMAIL PROTECTED]>
> Cc: "Postgres development" <[EMAIL PROTECTED]>
> 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   [EMAIL PROTECTED]
> >
> >
> > ---(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 [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Jan Wieck]

Tom Lane wrote:
> 
> "Al Sutton" <[EMAIL PROTECTED]> 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.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Tom Lane]

"Al Sutton" <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Stephan Szabo]

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.



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Win32 port patches submitted

[Al Sutton]

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" <[EMAIL PROTECTED]>
To: "Jan Wieck" <[EMAIL PROTECTED]>
Cc: "Postgres development" <[EMAIL PROTECTED]>
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   [EMAIL PROTECTED]
>
>
> ---(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: [HACKERS] Win32 port patches submitted

[Jan Wieck]

Tom Lane wrote:
> 
> Peter Eisentraut <[EMAIL PROTECTED]> 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.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Win32 port patches submitted

[Tom Lane]

Peter Eisentraut <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Win32 port patches submitted

[Peter Eisentraut]

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   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Win32 port patches submitted

[Jan Wieck]

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.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org