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
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
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
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 reason I
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 not
*) 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 way to
*) 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 #defined to the
] [mailto:pgsql-patches-
[EMAIL PROTECTED] On Behalf Of Magnus Hagander
Sent: Sunday, April 23, 2006 1:11 PM
To: pgsql-patches@postgresql.org
Subject: [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
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 compatible one.
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 way
[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 main difference between what I'm trying now from most of what
I've
-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 in place
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 at
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 code (gcc
14 matches
Mail list logo
