> > 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
> > *) 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
"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
> > > *) 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
> >> 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};
> 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
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
"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
> 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
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.).
Two downsides: One, is it makes the makefiles ugly, the other is
> 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
> -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'll need a VC buildfarm member
> -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] Building with Visual C++
>
>
>
> > -Original
"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
Patch applied, and catalog version updated.
---
Bruce Momjian wrote:
>
> Here is an updated patch. I broke out the statement_timestamp and
> statement_timeout handling into separate functions, initialize_command()
> and fi
On Sat, 22 Apr 2006, Tom Lane wrote:
> Given that we've already got a test for ICC in there as of today, I'd
> vote for adding -mp1 to CFLAGS if we see it's ICC.
This patch seems to do the trick...
Index: configure.in
===
RCS file:
16 matches
Mail list logo
