What do the Windows pg hackers out there like for dev tools?
Subject line says it all. I'm going to be testing changes under both
Linux and WinXP, so I'm hoping those of you that do M$ hacking will
pass along your list of suggestions and/or favorite (and hated so I
know what to avoid) tools.
TiA,
Ron
On 2/10/06, Ron <rjpeace@earthlink.net> wrote:
Subject line says it all. I'm going to be testing changes under both
Linux and WinXP, so I'm hoping those of you that do M$ hacking will
pass along your list of suggestions and/or favorite (and hated so I
know what to avoid) tools.
If you mean hacking postgresql source code, you pretty much have to
use the built in make/build system...this more or less rules out IDEs
and such.
I like UltraEdit for a text editor. Another good choice for editor is
source insight. Winmerge is a fantastic tool and you may want to
check out wincvs/tortoisesvn if you want to do checkouts from the gui.
Of course, to make/build postgresql in windows, you can go with cygwin
or mingw. cygwin is a bit easier to set up and has a more of a unix
flavor but mignw allows you to compile native executables.
The upcoming windows vista will most likely be able to compile
postgresql without an external build system.
Merlin
Ron wrote:
Subject line says it all. I'm going to be testing changes under both
Linux and WinXP, so I'm hoping those of you that do M$ hacking will pass
along your list of suggestions and/or favorite (and hated so I know what
to avoid) tools.
Testing only? So you really only need to build and run on Windows...
I was doing exactly this about a year ago and used Mingw. The only
annoyance was that I could compile everything on Linux in about 3
minutes (P4 2.8Ghz), but had to wait about 60-90 minutes for the same
thing on Windows 2003 Server! (also a P4 2.8Ghz...). So I used to build
a 'go for coffee' task into the build and test cycle.
Cheers
Mark
Mark Kirkwood <markir@paradise.net.nz> writes:
I was doing exactly this about a year ago and used Mingw. The only
annoyance was that I could compile everything on Linux in about 3
minutes (P4 2.8Ghz), but had to wait about 60-90 minutes for the same
thing on Windows 2003 Server! (also a P4 2.8Ghz...). So I used to build
a 'go for coffee' task into the build and test cycle.
Youch! That seems unbelievably bad, even for Microsloth. Did you ever
identify what was the bottleneck?
regards, tom lane
Mark Kirkwood <markir@paradise.net.nz> writes:
I was doing exactly this about a year ago and used Mingw. The only
annoyance was that I could compile everything on Linux in about 3
minutes (P4 2.8Ghz), but had to wait about 60-90 minutesfor the same
thing on Windows 2003 Server! (also a P4 2.8Ghz...). So I used to
build a 'go for coffee' task into the build and test cycle.Youch! That seems unbelievably bad, even for Microsloth.
Did you ever identify what was the bottleneck?
The mingw gcc compiler is horribly slow. It has nothing to do with
Microsoft this time. I haven't seen times quite that bad, but it's much
slower than gcc on Linux.
(As a comparison, completely rebuilding pgAdmin3 with Visual C++ on my
slow laptop takes maybe 5-6 minutes, whereas it takes 20+ minutes on a
Athlon64 3200+, with a much faster SATA disk and twice the memory. And
it's almost as slow on a dual-CPU server with high-speed SCSI disks. So
Visual C++ certainly doesn't have this problem.)
//Magnus
Import Notes
Resolved by subject fallback
Tom Lane wrote:
Mark Kirkwood <markir@paradise.net.nz> writes:
I was doing exactly this about a year ago and used Mingw. The only
annoyance was that I could compile everything on Linux in about 3
minutes (P4 2.8Ghz), but had to wait about 60-90 minutes for the same
thing on Windows 2003 Server! (also a P4 2.8Ghz...). So I used to build
a 'go for coffee' task into the build and test cycle.Youch! That seems unbelievably bad, even for Microsloth. Did you ever
identify what was the bottleneck?
No - I was connecting using an RDB client from a Linux box (over a LAN),
so was never sure how much that was hurting things... but (as noted by
Magnus) the compiler itself is noticeablely slower (easily observed
during the 'configure' step).
cheers
Mark