Re: [PATCHES] Building with Visual C++

Hi Magnus. I understood that this helped. #define PGBINDIR "/usr/local/pgsql/bin" #define PGSHAREDIR "/usr/local/pgsql/share" #define SYSCONFDIR "/usr/local/pgsql/etc" #define INCLUDEDIR "/usr/local/pgsql/include" #define PKGINCLUDEDIR "/usr/local/pgsql/include" #define INCLUDEDIRSERVER "/usr/lo

Re: [PATCHES] Building with Visual C++

> > BTW, has anyone looked at the possibility of driving VC > from gmake, so > > that we can continue to use the same Makefiles? Or is that > just out > > of the question? > > The Coin 3D project had a wrapper program that makes VC look > like a Unix compiler. Looking at >

Re: [PATCHES] Building with Visual C++

Tom Lane wrote: > BTW, has anyone looked at the possibility of driving VC from gmake, > so that we can continue to use the same Makefiles? Or is that just > out of the question? The Coin 3D project had a wrapper program that makes VC look like a Unix compiler. Looking at

Re: [PATCHES] Building with Visual C++

> I am sorry in a very late reaction... No problem. > > >>> We'll need a VC buildfarm member in place to catch us > anytime we > > >>> change the Makefiles in a way that the script doesn't > understand. > > >> > > >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed. > > This is

Re: [PATCHES] Building with Visual C++

From: "Magnus Hagander" I am sorry in a very late reaction... >>> We'll need a VC buildfarm member in place to catch us anytime we >>> change the Makefiles in a way that the script doesn't understand. >> >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed. This is a trial in the

Re: [PATCHES] Building with Visual C++

> >>> We'll need a VC buildfarm member in place to catch us anytime we > >>> change the Makefiles in a way that the script doesn't understand. > >> > >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed. > > > Y'know I say that, but thinking about it I imagine the buildfarm is > > tied

Re: [PATCHES] Building with Visual C++

"Dave Page" writes: >>> We'll need a VC buildfarm member in place to catch us anytime we >>> change the Makefiles in a way that the script doesn't understand. >> >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed. > Y'know I say that, but thinking about it I imagine the buildfarm is

Re: [PATCHES] Building with Visual C++

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page > Sent: 24 April 2006 22:35 > To: Tom Lane; Magnus Hagander > Cc: Chuck McDevitt; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] B

Re: [PATCHES] Building with Visual C++

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: 24 April 2006 21:57 > To: Magnus Hagander > Cc: Chuck McDevitt; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] Building with Visual C++ > > We&#x

Re: [PATCHES] Building with Visual C++

> The Microsoft VC++ compiler can definitely be driven by gmake > (I've done it at previous companies), but that involves a lot > of platform-specific knowledge added to the makefiles (.obj > instead of .o, .exe instead of no suffix, etc.). It also requires major hackery to make all the command

Re: [PATCHES] Building with Visual C++

m: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, April 24, 2006 1:57 PM > To: Magnus Hagander > Cc: Chuck McDevitt; pgsql-patches@postgresql.org > Subject: Re: [PATCHES] Building with Visual C++ > > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > The ma

Re: [PATCHES] Building with Visual C++

> BTW, has anyone looked at the possibility of driving VC from > gmake, so that we can continue to use the same Makefiles? Or > is that just out of the question? I tried. It really didn't work. There are just too many assumption of "unix cc style behaviour" in Make, and the VC compiler is just

Re: [PATCHES] Building with Visual C++

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > The main difference between what I'm trying now from most of what I've > seen before is that I *don't* want to create a separate build > environment that needs to be maintained. Instead have a conversion > script from our current one to a VC compatibl

Re: [PATCHES] Building with Visual C++

I've done a similar thing myself (building the complete backend with Visual Studio 2005). I got it to basically work, but stopped due to lack of interest in the PostgreSQL community. But, I'd be happy to help out your effort in any way I can. > -Original Message- > From: [EMAIL PROTECTED

Re: [PATCHES] Building with Visual C++

> I've done a similar thing myself (building the complete > backend with Visual Studio 2005). I got it to basically > work, but stopped due to lack of interest in the PostgreSQL community. Well, I'm one of those previously with lack of interest :-) The main difference between what I'm trying n

Re: [PATCHES] Building with Visual C++

> >> If they're going to be that anally uncooperative, why > don't they have > >> the required-by-C99-spec macro for NAN? Or at least some > >> well-defined way to generate a NaN? > > > They do have one way that's documented on MSDN, which is: > > unsigned long nan[2]={0x, 0x7fff};

Re: [PATCHES] Building with Visual C++

> > > *) Add s_lock implementation based on InterlockedCompareExchange > > > instead of assembly code (gcc style asm not supported, and > > this should > > > probably be about as fast from what I hear) > > > > _InterlockedCompareExchange is even better IMHO ... > > I could've sworn the non-_ was

Re: [PATCHES] Building with Visual C++

"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> If they're going to be that anally uncooperative, why don't >> they have the required-by-C99-spec macro for NAN? Or at >> least some well-defined way to generate a NaN? > They do have one way that's documented on MSDN, which is: > unsigned long n

Re: [PATCHES] Building with Visual C++

> > *) Change where NaN is generated. Using 0.0/0.0 doesn't > work in VC++ > > because it detects it as a divide-by-zero at the compile stage. > > If they're going to be that anally uncooperative, why don't > they have the required-by-C99-spec macro for NAN? Or at > least some well-defined wa

Re: [PATCHES] Building with Visual C++

> > I've been working on getting the full backend to compile > and run using > > Visual C++ instead of mingw/gcc, and have made some good progress. > > > > This is great! Thanks. > > *) Add s_lock implementation based on InterlockedCompareExchange > > instead of assembly code (gcc style asm

Re: [PATCHES] Building with Visual C++

""Magnus Hagander"" <[EMAIL PROTECTED]> wrote > I've been working on getting the full backend to compile and run using > Visual C++ instead of mingw/gcc, and have made some good progress. > This is great! > *) Add s_lock implementation based on InterlockedCompareExchange instead > of assembly co

Re: [PATCHES] Building with Visual C++

"Magnus Hagander" <[EMAIL PROTECTED]> writes: > *) Change where NaN is generated. Using 0.0/0.0 doesn't work in VC++ > because it detects it as a divide-by-zero at the compile stage. If they're going to be that anally uncooperative, why don't they have the required-by-C99-spec macro for NAN? Or a